2013-05-06T20:29:25-05:00 http://securityblog.org Joshua Brindle 2013-04-30T00:00:00-05:00 http://securityblog.org/2013/04/30/se-android-and-the-motochopper-exploit <h3>SE Android prevents first exploit against commercial phone</h3> <p>That should have been the title of this post, but alas it is not.</p> <p>By now you may know that the Samsung Galaxy S4 is the first commercial device shipped with SE Android included.</p> <p>Included, but not enforcing. If you are familiar with SELinux you know that there is a developer mode (also called permissive) that audits access that would have been denied, but does not actually deny them. This is very useful for developing your policies without having to interate through accesses one at a time (this takes a very very long time with complex software).</p> <p>The standard way of writing policy is to use permissive mode to run an application, then look at the logs and figure out what the access patterns are, what should be labeled what, write the policy, then try again. Eventually you go into enforcing mode when you are ready to send your product to production.</p> <p>That is the theory, anyway.</p> <h3>History lesson</h3> <p>Back in the Fedora 2 days (that is 2004) SELinux shipped in enforcing, with a strict policy. It was a catastrophy. Linux users who were accustumed to cat'ing /dev/cdrom, for whatever reason, became angry that they couldn't do it all of a sudden. The targeted policy was then created which would resrtict only high-threat applications, like apache and ssh. Most recently Dan Walsh, over at Red Hat, introduces new application policies to the masses in permissive mode (note, SELinux supports permissive mode per-type, not just system wide) and collects denials from users for a few months, to figure out how people use the applications, since he can't be an expert at every single one. He then switches the policy to enforcing when the policy has been fleshed out.</p> <h3>Lost Opportunity</h3> <p>This is the first commercial phone with SE Android; there is a huge amount of risk to going into the wild in enforcing. I don't know if they were nervous that something like Fedora 2 would happen or it was carrier certification delays or perhaps they just don't think SE Android should be on unless explicitely requested. No matter what the reason, a huge opportunity to show the world the power of SE Android was lost. No worries, though, there will be another opportunity.</p> <h3>The Exploit</h3> <p>Ok, lets look at this exploit and see what would have happened. I don't happen to have a Galaxy S4 in front of me, but the stock recovery image has everything I need to look at this.</p> <p>First, the <a href="http://forum.xda-developers.com/showthread.php?t=2252248">exploit</a> is motochopper and was originally written for a Motorola. The reason it works on the S4 is that the phones have similar chipsets. The chipset vendors provide kernel patches, drivers, userspace components, etc to the OEM's. The OEM's then integrate that into their version of Android, normally what Google gives them + their extras. In this case the vulnerability was in the code provided by the chipset, it had a world writable fb0 device node, that allowed an mmap() of kernel memory.</p> <p>Without a phone in front of me, how on earth could I know that the exploit wouldn't have worked, you ask?</p> <p>Edit: The above isn't quiet accurate. The vulnerability <a href="http://forum.xda-developers.com/showthread.php?p=40873964">was a bug in the mainline framebuffer</a> rather than in a specific chipset, which means it may affect even more devices.</p> <h3>The Policy</h3> <p>On the recovery ROM are 2 files that I can use to mount this investigation. I know the exploit mmap()'s /dev/graphics/fb0 so first I want to know what that would be labeled:</p> <pre><code>$ grep /dev/graphics file_contexts /dev/graphics(/.*)? u:object_r:graphics_device:s0 </code></pre> <p>So, /dev/graphics/fb0 (and indeed everything under the graphics directory) would be labeled graphics_device.</p> <p>On SE Android the type you get when you use adb shell is shell. So, next I need to look for accesses between shell and graphics_device:</p> <pre><code>$ sesearch --all -s shell -t graphics_device sepolicy Found 7 semantic av rules: allow appdomain dev_type : file getattr ; allow appdomain dev_type : dir { ioctl read getattr search open } ; allow appdomain dev_type : lnk_file { read getattr } ; allow appdomain dev_type : chr_file getattr ; allow appdomain dev_type : blk_file getattr ; allow appdomain dev_type : sock_file getattr ; allow appdomain dev_type : fifo_file getattr ; </code></pre> <p>Indeed there is no write permission so the mmap attempt to write to kernel memory would fail. This only covers the adb shell case though, and that is typically done by the owner of the device. Granted that this makes problems for BYOD but the more interesting question is, could malicious apps exploit this?</p> <p>In the seapp_contexts file it shows that third party apps will be labeled untrusted_app, so lets look at that:</p> <pre><code>$ sesearch --all -s untrusted_app -t graphics_device sepolicy Found 7 semantic av rules: allow appdomain dev_type : file getattr ; allow appdomain dev_type : dir { ioctl read getattr search open } ; allow appdomain dev_type : lnk_file { read getattr } ; allow appdomain dev_type : chr_file getattr ; allow appdomain dev_type : blk_file getattr ; allow appdomain dev_type : sock_file getattr ; allow appdomain dev_type : fifo_file getattr ; </code></pre> <p>Again, no dice. Apps can stat() the file but not read or write it. The same goes for the browser (browser_app) and even platform_app, which includes all of the apps included on the device from Samsung and Google.</p> <p>But which types <em>can</em> write to the file? Good question, SE Android may be blocking all of this access but we know the vulnerability is there, we should find out what on the system is able to exploit it:</p> <pre><code>$ sesearch -t graphics_device --allow -c chr_file -p write sepolicy Found 7 semantic av rules: allow system graphics_device : chr_file { ioctl read write getattr lock append open } ; allow system_app graphics_device : chr_file { ioctl read write getattr lock append open } ; allow mediaserver graphics_device : chr_file { ioctl read write getattr lock append open } ; allow unconfineddomain dev_type : chr_file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod open audit_access } ; allow mm-pp-daemon graphics_device : chr_file { ioctl read write getattr lock append open } ; allow surfaceflinger graphics_device : chr_file { ioctl read write getattr lock append open } ; allow bintvoutservice graphics_device : chr_file { ioctl read write getattr lock append open } ; </code></pre> <p>Well, system and system_app, which are pretty powerful either way, granted it is an escalation if you can compromise them. unconfineddomain (hrm.. whats that?), the seapp_contexts file doesn't have any entries for it, so presumably it is there for MDM/MAM vendors to run unconfined apps if they choose to. surfaceflinger obviously needs to be able to write to the graphics device, and possibly mediaserver. bintvoutservice probably does too, and I don't know what mm-pp-domain is, probably a Qualcomm specific thing.</p> <p>So, there are definitely vectors to get at this, but they involve compromising protected apps (in a real security analysis we'd keep backtracking to see what vectors there are to attack system and system_app, for example) but this exploit wouldn't have been pulled off nearly as easily as it was, if SE Android were enforcing.</p> <h3>Conclusion</h3> <p>Exploits like this are scary, not because of owners that want to root their phones but because, if an owner can do it, it is highly likely that an adversary can. These mobile devices are our lives, they have business data on them, they have private data, and they can be used to steal your money in various ways (such as premium SMS's). There will not be a shortage of vulnerabilities until OEM's and users alike start thinking from a security mindset. The tools are there, no OEM has an excuse not to use them.</p> <p>It may not be a bad idea to set SE Android into enforcing once you've rooted your phone, so that malicious apps don't take advantage of the same vulnerability, if I get my hands on a GS4 I'll blog about doing that.</p> 2013-04-12T00:00:00-05:00 http://securityblog.org/2013/04/12/and-here-it-is-mrats-found-that-bypass-mdm <p>As a follow-up to my <a href="http://securityblog.org/2013/04/11/security-anti-pattern-mobile-castles-on-sand/">last blog post</a>, I just came across this article: <a href="http://www.infosecurity-magazine.com/view/31801/mobile-malware-gets-serious-rats-can-bypass-sandboxes-and-encryption/">Mobile malware gets serious – RATs can bypass sandboxes and encryption</a></p> <p>1 in 1000 devices, the tools are in the wild. There is no reason to believe this number will go down. Further, these mRAT's apparently know how to bypass MDM and MAM sandboxes and encryption.</p> <p>of course, <a href="http://blogs.computerworld.com/19803/mobile_rat_attack_makes_android_the_ultimate_spy_tool">mRAT's</a> <a href="http://365.rsaconference.com/community/connect/blog/2012/02/21/rsac2012-podcast-hot-203-hacking-exposed-mobile-rat-edition">aren't</a> <a href="http://www.talkandroid.com/52495-malware-strain-nickispy-c-is-exploiting-the-rise-of-google/">anything new</a>, but this is the first I've heard about ones that specifically target/bypass MDM/MAM.</p> <p>Worse, the tools aren't just being used by experts; hackforums.net has tutorials on using them with commands like 'Hit Start then run, type "CMD" without quotations, hit OK, type "IPCONFIG" without quotations, etc'.</p> <p>The solution is integrating SE Android into your devices; but SE Android, like SELinux is no silver bullet. You need good policies. Mobile device manufacturers are notoriously bad at securing their devices. The fact that a device node directly exposing kernel memory was world readable/writeable on many Samsung devices is direct evidence of this. The same people writing that software could not possibly be trusted to write secure SELinux policies. Separate teams that do security analysis and testing must ensure the policies are reasonable, etc.</p> <p>This isn't rocket science, but it isn't standard operating procedure either. We've been doing independent verification and validation (IV&amp;V) in government spaces forever. This needs to happen in mobile and there need to be security mechanisms that don't rely on discretionary access controls in place, which, of course, means mandatory access controls, which SE Android offers.</p> 2013-04-11T00:00:00-05:00 http://securityblog.org/2013/04/11/security-anti-pattern-castles-on-sand <h1>Mobile Application Management (MAM)</h1> <p>Mobile Device Management (MDM) was all the hotness just a few years ago. It gave IT departments the ability to manage both corporate owned devices and devices owned by employees (BYOD) but it was dissatisfying. As BYOD became more prevalent and corporate owned devices less it made users feel like they were giving up all control of their device to their employer, mainly because they were. Most users at this point probably know the feeling of adding their corporate credentials into their phone and seeing the dreaded 'you are giving administrators the ability to wipe your phone, install apps, remove apps, and locate your phone' screen.</p> <p>Then there was the issue of having multiple administrators that wanted to do different things with your device.</p> <p>Even for the administrators, the solution was incomplete. It did not give them the ability to manage app configuration, app storage, app authentication, etc.</p> <p>That is where MAM comes in. For the administrators it means they can package apps with configuration, version it, push it out and wipe only corporate app data when an employee leaves. The nicer systems add single sign-on so that a user can authenticate once and get access to all corporate apps. They also store corporate data encrypted and can report usage statistics back to corporate IT. For users it means that they don't have to give up full control of their device.</p> <p>Sounds great, right?</p> <h2>How does it work?</h2> <p>Well, mobile devices don't typically have this kind of granular control built in. Further, off-the-shelf applications generally don't come configured or support single sign-on. The solution that MDM vendors started peddling is called app wrapping. Basically it means that the IT department takes the apps they want to manage (whether they are internally developed or 3rd party) and runs a tool from the MAM vendor that packages the app within another app, the wrapper (or the castle).</p> <p><img src="/images/castle.png" title="Icons from http://wwalczyszyn.deviantart.com/" alt="Apps in a castle" /></p> <p>The outside package interacts with the real device, including storing data to disk encrypted, verifying credentials with corporate authentication servers, etc. The fancier ones even prevent apps from running outside of specific physical locations (geofencing), and will attempt to detect a rooted device (though that is impossible in practice).</p> <p>So, this still sounds great. From a functionality point of view this is a superior experience for both the user and IT, so what is the problem?</p> <h2>Userspace containerization (or building castles)</h2> <p>Lets start with the obvious one first. The inside (wrapped) app is modified to not be able to interact with the real device, but to interact with the wrapper instead. Two standard ways this is done is by providing an SDK that corporate apps can be written with and the other is called app wrapping. It should be noted that while using the SDK is the safer option, it will likely lock you in to a single MAM vendor.</p> <p>App wrapping on Android involves modifying the Dalvik bytecode ahead of time to add all of the functional additions as well as changing functions that would normally interact directly with the system (think filesystem operations, intents, binder calls, etc) to use analogous calls in the wrapper instead. The effect here is that the wrapper can 1) ensure filesystem writes only go to allowed locations and are encrypted and 2) to prevent IPC with apps outside of the "container".</p> <p>Well, that is the thought, anyway.</p> <p>No one in their right mind would believe that they can write a libc wrapper that intercepts open() calls to make security decisions and think that it buys them anything, but that is fundamentally what is happening here. App wrappers cannot contain numerous, supported features on Android such as jni to native libraries and java reflection. A particularly crafty app might even have a scripting language interpreter or its own java class loader that would be nearly impossible for the wrapper to understand and secure.</p> <p>There is no chance that an MAM implementation could keep an app that wanted to exfiltrate corporate data from doing so. That is an easy problem to solve though, you only wrap trusted apps, because they are either corporate or known 3rd party apps, right? Well, hopefully, for your sake, those apps don't have vulnerabilities that a spear phisher can take advantage of to gain access to corporate data (spoiler: they do).</p> <p>In the scheme of things this is a relatively low threat, though, so lets move onto the real issue.</p> <h2>The insecure platform (or the sand)</h2> <p>People have tried building secure on top of insecure as long as personal computers have been around. The appeal is that there is always an insecure platform, be it Windows, Linux, iOS, or Android and there is always a need to access secure data is always there.</p> <p>I'll take this opportunity to suggest that, if you haven't already, you should read: <a href="http://csrc.nist.gov/nissc/1998/proceedings/paperF1.pdf">The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments</a></p> <p>The fact is that if the system below your application isn't secure no amount of anything will make your application (or wrapper) secure. Detecting rooted devices is not enough. Most detection is heuristic, such as checking for the existence of /system/xbin/su. Suppose the device is not rooted by the user such that su exists but by an adversary? Root access gained for the intention of stealing corporate data would not likely be detected by an MAM solution and therefore malicious applications running on the device would be able to affect the corporate apps in various ways, from communicating with them, bypassing the wrapper, all the way to scanning their memory and extracting corporate data.</p> <p>Most snake oil vendors will claim encryption solves this problem. Encryption may be a suitable solution to data-at-rest, data not currently being accessed that is sitting on disk, but when your corporate email app is running the emails are in memory, not encrypted. Even if an industrious app writer did extra work to keep them encrypted in memory the decryption key must also be in memory, and is vulnerable.</p> <p>So, this is the real threat. If your app has data I want and it runs on a standard Android or iOS phone, I'll be able to get it, no matter what your MAM vendor is telling you.</p> <p>As a non-security related aside, you probably don't have permission to download 3rd party apps from the app store and wrap them, which would constitute unlicensed distribution, you'd have to get permission from the app owner. An interesting ramification of this is that GPL apps can't be legally wrapped since the GPL license of the app would have to apply to the wrapper as well.</p> <h1>The solution</h1> <p>Just like in standard computing the solution isn't hard, but is rarely used.</p> <p>You must have a secure host platform if you want your applications to be secure. Unfortunately not many options exist for this but fortunately there are options that are freely available. The one that I favor is, of course, SELinux. I've been involved in building SELinux systems to secure even the most important data for nearly a decade now and it has proven true.</p> <p>Anecdotally, I have security researcher friends who work on the offensive side of the fence that have told me when they encounter an SELinux machine they bail and look for an easier target. It is important to note that we aren't talking about out-of-the-box Fedora installs, though, but systems intentionally and knowingly hardened against this type of adversary.</p> <p>Which brings us back to Android. The Security Enhanced Android (SE Android) project has been picking up more and more steam. Much of it is already merged into AOSP which allows all Android vendors to use it and recently Samsung has announced a device that will have it included by default. This is definitely a step in the right direction but a far cry from what it will take to feel confident allowing important corporate data to be accessed on non-corporate owned devices.</p> <p>With a secure platform you can enjoy the functionality benefits of an MAM solution and be confident that security provided by the platform will keep their castles secure, both from the inside and the outside.</p> <p>Unfortunately, none of this is a solution you can use today. Technology must, as usual, catch up to market demands. The demand must be there, though. Demand secure platforms. There is no excuse for Android vendors to not include SE Android in future offerings, all the hard work has already been done by early adopters.</p> <p>Update: My <a href="http://securityblog.org/2013/04/12/mrats-bypass-mam/">next entry</a> has validation for this post, seen in the wild.</p> 2013-02-11T00:00:00-06:00 http://securityblog.org/2013/02/11/security-anti-pattern-mobile-hypervisors <p>One of the things I was working on for most of 2012 was mobile security, specifically SE Android.</p> <p>My exposure to mobile was limited to using smart phones and making minor customizations to third party ROM's before 2012.</p> <p>That would all change. A group of us started looking at a specific RFP that many believed would be the major mobile entréinto the federal government and military. It wasn't. It turned into a fiasco.</p> <p>What it did do, however, was solidify many people's belief that hypervisors on mobile platforms was the way to achieve multi-level cross domain access. It convinced me that they couldn't be more wrong.</p> <p>Since then, my colleagues and myself were on a mission to convince the world that virtualization on mobile for security is the wrong answer. Now that I am out on my own I want to take this opportunity to share some of my own beliefs on the matter.</p> <p>First a CYA part: Although these beliefs were formed while I was working elsewhere I have no reason to believe they are proprietary and I don't, in any way, represent anyone except myself.</p> <h2>The Fiasco</h2> <p>At the beginning I, like everyone else, had no reason to doubt all the vendors out there selling mobile virtualization solutions. After all, they had demos, they had huge numbers like deployed on 1.5 billion devices. Many proposal writers would have been satisfied with this and gone to the next issue. However, because of the insane schedule requirements of this particular RFP I wanted to make sure there was software available <em>today</em> (which was March, 2012) that could be used immediately, on hardware that was already available.</p> <p>Boy, that is an interesting rabbit hole. Anyone working in mobile knows that information in general is hard to come by. Anecdotally, people working at major mobile device manufacturers sometimes have trouble getting spec sheets for their own phones. Mobile hypervisors are no exception, and possibly worse.</p> <p>Unlike Intel, which makes its own chips, ARM does not. Instead they license the chip designs to chip makers. Those makers, in general, are free to pick and choose various capabilities, extended instruction sets, add proprietary instruction sets, etc. They can even choose the endieness. This does not make a friendly environment for people who need to work very closely to the hardware, like a hypervisor developer.</p> <p>Like Intel, ARM has virtualization extensions. For quite a while, in fact. ARM also has TrustZone, which is made for DRM, but provides a secure-world split from the rest of the system, and can be used for a hypervisor. The challenge at the time was that <em>there were no mobile phones on the market that implemented either of these completely, correctly, or enabled</em>. Further, TrustZone configuration is available only to the chip maker. This means that hypervisors that run on these technologies quite possibly work, on a development board, but not on any phones. Finally, a hardware vendor admitted that they never enable things like TrustZone because they didn't want to get into the key management business. Yay.</p> <p>Well, there is still paravirtualization, right? Paravirtualization is great, really. Except that it requires modifying the OS, more specifically it means modifying the drivers. So, onto lesson #2 for the mobile noobs. No one gets driver source code except the chip manufacturers. That includes the people packaging them up into boards, the people building phones, the people building the OS for the phones, etc. Some chip manufacturers won't even let Google release <em>binary</em> blobs of their drivers on the website for Nexus devices, despite the fact that Nexus owners can unlock their phones and pull them all off.</p> <p>One conclusion was that, while someone with deep connections to the chip makers might be able to eventually produce a phone that can run a hypervisor for multiple guest operating systems, it wasn't happening with phones on the market at the time, it wasn't happening within the schedule of this particular RFP, and it certainly wasn't going to be us doing it.</p> <h2>Reset</h2> <p>So, now the belief I went into this with has been broken down. Why did we have that belief at all? Why did we start thinking it was the right answer? We fell into the same trap that everyone else did. The Cross Domain Solution community has forgotten its heritage. Virtualization has become the magic bullet for cross domain access solutions, but why?</p> <p>Once upon a time there were many trusted operating systems. They were mostly based on their non-trusted siblings. The names were straightforward; you had Trusted Solaris, Trusted IRIX, Trusted Xenix, etc. These were evaluated. You could run applications at multiple levels on them just fine. And people did, just not very many people.</p> <p>By the end of the UNIX wars, most of these systems were Trusted Solaris, but they still weren't in huge use. Most people had settled on Windows for their standard tasks. Windows applications didn't run on Trusted Solaris. In fact, modern Solaris applications didn't run on Trusted Solaris, which was typically a couple major releases behind.</p> <p>What to do? Well, SELinux was being developed. Virtualization was becoming possible on x86. The NSA tied the 2 together and released NetTop. You could now run Windows apps at multiple levels right next to each other on the same system, albeit very slowly. Then there were the various HAP (High Assurance Platform) projects, and other variations. Long story short, people started defaulting to 'virtualize for cross domain access', without even thinking.</p> <p>For mobile this trap can be avoided entirely. You have a platform, and people are using apps written for that platform, not for another platform. You don't need to virtualize to run the apps you want.</p> <h2>Security Anti-pattern</h2> <p>Up until now I've been focusing on why hypervisors aren't there for mobile, and why that was the default thought anyway, but not much about the security anti-pattern part. So lets get started on that.</p> <p>Mobile security is an interesting beast. It has all the issues of regular computing and a whole host of its own.</p> <h3>Power Management</h3> <p>Take power management, for example. On mobile systems you want the main application processor powered down as often as possible. How do you do that while maintaining a nice user experience? You don't want an app sitting in the background constantly polling for email, killing your battery, but you also don't want everything to fire up and go download data the instant the user unlocks the device, since that will make it unusable for some amount of time. Google implemented wakelocks for this purpose. They allow apps to notify the kernel that they are doing something, and that the kernel shouldn't put the device to sleep. You also want apps to be able to simultaneously use wakelocks, and let the system sleep sooner.</p> <p>Now, instead of just getting to the kernel above the apps, those wakelocks would need to make it all the way to the hypervisor. Further, without sharing wakelocks between VM's you'll have the same power draining serial usage of processor awake time.</p> <p>See what I did there? Automatic info-flow between VM's, regardless of whether you do it or not. If VM1 is doing something it'll keep the processor awake, VM2 will know. If you share wakelocks and VM1 is doing something VM2 will know.</p> <p>The old trusty high assurance MILS way of fixing this? Fixed time-slice scheduling. Give each VM X amount of time, move on to the next when time is up. In this world, how will the hypervisor know when to sleep? How do you manage talking on the phone, a somewhat real-time activity, if you are cycling through VM's? Finally, what is someone going to do with a phone that has a 1 hour battery life because VM's can't cooperate?</p> <p>So, choose between punching a hole in the hypervisor or getting miserable power performance.</p> <h3>Holes, holes everywhere</h3> <p>I already mentioned the issue with drivers. The current solution for hypervisors is to pass device access straight through to one (or more) of the VM's.</p> <p>This is pretty standard for all virtualization based cross domain solutions, actually. Hypervisors are suppose to be small, they can't have a graphics subsystem. By using an IOMMU they assign a single VM to manage graphics (and nothing else) and then assign the DMA memory range of the device to that VM. No other VM can access that memory, so then you build one-way pipelines from all the VM's to the graphics VM and let it do compositing, etc.</p> <p>As a sidenote, none of the solutions I know of actually have shared 3d acceleration, if you need 3d acceleration you have to lock a single VM to a video card.</p> <p>So, back to mobile. You <em>might</em> be able to find an SoC with a working IOMMU, but I wouldn't count on it. I could find nothing of the sort back then.</p> <p>This same method is used for all kinds of devices, such as networking. With networking, however, you now have 2-way communication. High assurance systems will need separate network cards that can each be assigned to a single VM. How do you do this on a mobile device, where there is generally one cellular radio? Typically the idea is that you have separate encryption VM's for each user facing VM.</p> <p>How many device VM's are you willing to have? How many paths through the hypervisor do you open? How much security do you end up having when every device is shared between all VM's? What is the performance and power penalty if a simple action like downloading some data from a website, storing it to the filesystem and displaying a message to the screen involves no fewer than 4 VM's?</p> <p>In the end you have VM's that are trusted to do the separation between user-facing VM's instead of having the hypervisor solely doing that. This means that all those assurance arguments and the fact that your hypervisor only has 10k lines of code is irrelevant. You've just added a bunch of Linux kernels to your trusted base.</p> <p>In desktop virtualization based solutions these device managing VM's were typically SELinux systems. SE Android could be similarly used to lock down these systems, and at the time it was just being released. I figured that since it had to be done anyway, in order for the hypervisor use case to ever work, I might we well focus on it. At least then there would be a secure platform that could be used until the whole hypervisor thing got resolved. At this point my opinion is that even if they are available and working they aren't worth it, but I know many who disagree.</p> <h3>Functionality</h3> <p>Security is always at odds with functionality, by definition. Mobile users have fairly high expectations of their devices. One example is the ability to receive phone calls. Personally I have bad experiences with my smart phones receiving phone calls without extra security so this is a serious uphill battle.</p> <p>So, if a user is using a secret level VM, and his child's school calls on the unclass VM to tell him that his child has been hurt and is going to the hospital, should he be able to be receive that call? I don't think many people would want to use these devices if the answer is no, but what does saying yes entail? More holes punched through the hypervisor? Probably, but you've already made plenty of those.</p> <p>How about the baseband processor? Oh, right, I haven't mentioned that yet. Pretty much every smart phone has a whole 'nother processor, operating system and software stack connected to the radio. Sometimes this processor is actually primary (it bootstraps and starts the application processor).</p> <p>So, on some smart phones the baseband processor is connected directly to the microphone. Obviously while in the secret VM access to the microphone must be restricted. What does this mean? There must be a VM managing communication with the baseband processor, so it is going to have to make the hard decision as to allow the microphone to be used while a secret VM is active. This, obviously, opens all sorts of serious issues.</p> <p>There are many other examples of this. Switching between 5 VM's to check email isn't going to make anyone happy. Not getting text messages from the wife while at work may not make your home life better.</p> <h2>Conclusion</h2> <p>You'll notice that the title of this entry specifically mentions user facing VM's on mobile devices. I do not object to using a hypervisor in conjunction with a specialized integrity measurement and monitoring system for attestation purposes. The device access necessary to such a VM would be minimal, and it would only need to do something when an attestation request was made, so it has no reason to wake up the phone. It also doesn't add many VM's that need to constantly be scheduled.</p> <p>I <em>do</em> object to the sentiment that a hypervisor is <em>required</em> for multi-level cross domain access on a mobile device. I believe the sentiment is guided by where the desktop multi-level market landed, without the requirements that got it there. Additionally, I believe, by the time you have a functional implementation you won't have any more assurance than running an SE Android system that implements multi-level access controls. On top of that, the system will be significantly less usable, battery life and performance will suffer, and you'll never get away from having to modify the underlying OS anyway.</p> <p>SE Android is being developed at a rapid pace and new features are added often. I can't wait to see where it goes, but I hope the hypervisor evangelists aren't able to take the steam out of it before it gets there.</p> 2013-02-06T00:00:00-06:00 http://securityblog.org/2013/02/06/big-changes <p>New blogging system... Also I left Tresys.</p> <p>After almost 9 years there I have resigned, which was a hard thing to do.</p> <p>Spencer Shimko, Brandon Whalen and I left Tresys a couple weeks ago to start our own company, <a href="http://quarksecurity.com/">Quark Security</a>. That decision wasn't easy but it is a good time in our careers and we all believe that we are prepared to succeed running our own company. We were joined by an ex-Tresys employee, Ed Sealing.</p> <p>So, after a very crazy 2012, almost entirely focusing on mobile security for me, we are going forward, trying to figure out how to make our mark on the world. We are learning about the nitty gritty details about government contracting that we were never exposed to before. It is all very fascinating and definitely unlike what I've done before.</p> <p>Strangely enough, my workload is much lighter at the moment, than it was before I left, so I hope to be able to spend some time writing up my thoughts on various things, including mobile security, before I get ramped back up to pre-leaving workloads.</p> 2009-10-24T00:00:00-05:00 http://securityblog.org/2009/10/24/the-selinux-documentation-project <p>One of the biggest complaints people have about SELinux is the lack of documentation. Indeed we had a nice group discussion with some users at Linux Plumbers Conference who once again brought this to our attention.</p> <p>The reason is simple. Most of us working on SELinux are developers. We don't like writing documentation. We'd rather write blog entries explaining some aspect of SELinux instead of real documents. While this works when your primary audience are knowledgeable enough to find the blog entries, figure out how to apply the concepts to their problems and connect all the dots between here and there it isn't useful for new users or users trying to solve a simple problem.</p> <p>It is unfortunate, and some people over the years have helped us out, such as with the <a title="Fedora SELinux User Guide" href="http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/" target="_blank">Fedora SELinux User Guide</a>, but unfortunately we've missed some users, particularly new ones, and we haven't aggregated these documents onto a distribution agnostic place with good organization.</p> <p>With that in mind I volunteered to start the SELinux Documentation Project during LPC. Basically the goal is to make user-problem focused documentation available at the official <a title="selinux project site" href="http://selinuxproject.org" target="_blank">SELinux project site</a>. This will be a huge effort, writing original documentation, organizing it into consumable chunks and mining years of mail list posts, blog entries and other resources to deliver documents to users.</p> <p>I've already started putting up several pieces. One of the things I want to really focus on are SELinux ‘recipes', short, to-the-point blurbs telling users how to do the things they want to do, like<a href="http://selinuxproject.org/page/ApacheRecipes#Allow_Apache_to_connect_to_your_database_server" target="_blank"> allowing apache to connect to their database server</a>, or  how to <a title="Adding a rule with audit2allow" href="http://selinuxproject.org/page/Audit2allowRecipe" target="_blank">easily add a rule to their policy</a>.</p> <p>We also need a place where potential developers can go to <a title="developer resources" href="http://selinuxproject.org/page/Developers" target="_blank">easily get resources on developing SELinux</a> so that our community can expand. Further a place where vendors can go to learn about what SELinux can do for their solution and how to get started using SELinux is a must.</p> <p>All that said, I can't do this alone. I've started several pages and will continue doing so but if you are one of those strange souls with a propensity to document things, or you have recently gone through the pains of finding info in obscure places that you couldn't find elsewhere we could really use your help in expanding, organizing and centralizing documentation on <a title="selinuxproject" href="http://selinuxproject.org" target="_blank">selinuxproject.org</a>. If you want to help you can email me at method at manicmethod.com or James Morris at jmorris at namei.org to get an account and start contributing.</p> 2009-10-24T00:00:00-05:00 http://securityblog.org/2009/10/24/selinux-and-rpm <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> Wow, I just noticed it's been a year since I've blogged, that is not good. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> That doesn't mean nothing has been going on though, we've been quite busy around here. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> First I'd like to talk about a couple projects we are working on. The first is better integration of SELinux policies into RPM. We've posted a patch set to the rpm-maint [1] mailing list and are awaiting feedback. To try out the patches yourself you can read the instructions on the project page at selinuxproject.org [2]. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> The current patch set basically makes RPM actually do stuff with the %policy tag, which it never did before. We've also changed the %policy tag to be more flexible in allowing more information about the policies to be handled by RPM, such as policy modules that are being obsoleted. You can read the full description of the patches on the mail list postings [3]. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> This is only the first step in a long term project we have to make RPM more robust and reduce the amount of trust necessary in the package manager. We have several ideas of how to proceed but we haven't proven that they'll work yet (or that the RPM community will be interested in them). Suffice to say we basically want to break RPM into smaller pieces, each of which has a dedicated job to do, which can be confined by SELinux. Each step would require less trust that the packages aren't malicious and that the SELinux policy is correct and will enforce the security goals set forth by the packager. Once this is done we want to try running core parts of RPM in different security domains depending on different attributes about the package and who is running it, such as what certificates were used to sign the package, where the package came from, who is running RPM and so on. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> The culmination of this effort would be to be able to download a 3rd party package and install it knowing that it will only be able to add its files to /opt, and not modify anything in /usr, /lib, /etc, etc. Further the scriptlets should be confined so that they can't add users to the system or any other security critical activities. This will be a truly exciting capability for Linux systems moving forward. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> I delivered a presentation on this project at Linux Plumbers Conference last month in Portland. The slides [4] and video recording [5] are published on the web for those who are interested. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> I'll talk about another project we are working on in my next blog post, which should be coming pretty soon. </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> [1] https://lists.rpm.org/mailman/listinfo/rpm-maint </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> [2] http://selinuxproject.org/page/RPM </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> [3] http://lists.rpm.org/pipermail/rpm-maint/2009-October/002561.html </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> [4] http://linuxplumbersconf.org/2009/slides/brindle-selinux-distribution-lpc-slides.pdf </div> <div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;"> [5] http://video.linuxfoundation.org/video/1569 </div> <p>Wow, I just noticed it's been a year since I've blogged, that is not good.</p> <p>That doesn't mean nothing has been going on though, we've been quite busy around here.</p> <p>I'd like to talk about a couple projects we are working on. The first is better integration of SELinux policies into RPM. We've posted a patch set to the <a title="rpm-maint mailing list" href="https://lists.rpm.org/mailman/listinfo/rpm-maint" target="_blank">rpm-maint</a> mailing list and are awaiting feedback. To try out the patches yourself you can read the instructions on the <a title="RPM Project page" href="http://selinuxproject.org/page/RPM" target="_blank">project page at selinuxproject.org</a>.</p> <p>The current patch set basically makes RPM actually do stuff with the %policy tag, which it never did before. We've also changed the %policy tag to be more flexible in allowing more information about the policies to be handled by RPM, such as policy modules that are being obsoleted. You can read the full description of the patches on the<a href="http://lists.rpm.org/pipermail/rpm-maint/2009-October/002561.html" target="_blank"> mail list postings</a>.</p> <p>This is only the first step in a long term project we have to make RPM more robust and reduce the amount of trust necessary in the package manager. We have several ideas of how to proceed but we haven't proven that they'll work yet (or that the RPM community will be interested in them). Suffice to say we basically want to break RPM into smaller pieces, each of which has a dedicated job to do, which can be confined by SELinux. Each step would require less trust that the packages aren't malicious and that the SELinux policy is correct and will enforce the security goals set forth by the packager. Once this is done we want to try running core parts of RPM in different security domains depending on different attributes about the package and who is running it, such as what certificates were used to sign the package, where the package came from, who is running RPM and so on.</p> <p>The culmination of this effort would be to be able to download a 3rd party package and install it knowing that it will only be able to add its files to /opt, and not modify anything in /usr, /lib, /etc, etc. Further the scriptlets should be confined so that they can't add users to the system or any other security critical activities. This will be a truly exciting capability for Linux systems moving forward.</p> <p>I delivered a presentation on this project at Linux Plumbers Conference last month in Portland. The <a href="http://linuxplumbersconf.org/2009/slides/brindle-selinux-distribution-lpc-slides.pdf" target="_blank">slides</a> and <a title="video" href="http://video.linuxfoundation.org/video/1569" target="_blank">video recording</a> are published on the web for those who are interested.</p> <p>I'll talk about another project we are working on in my next blog post, which should be coming pretty soon.</p> 2008-10-09T00:00:00-05:00 http://securityblog.org/2008/10/09/red-hat-and-tresys-partner <p>For those who haven't <a href="https://www.redhat.com/about/news/prarchive/2006/tresys.html" target="_blank">seen this</a>, it is good news for everyone I think. Basically it means that the company that I work for, Tresys Technology, which has considerable security engineering experience and knowledge now has the ability to reach people who need those services, through Red Hat's services division. </p> <p>Up until now we have done primarilly government work so we've been somewhat out of touch with the needs of commercial Linux users, many of which need security expertise to meet regulations or to protect their customers privacy. I hope this turns in to a productive partnership, for us, them and their customers.</p> 2008-10-08T00:00:00-05:00 http://securityblog.org/2008/10/08/stackoverflowcom-and-the-selinux-poll <p>So, stackoverflow.com was released to public beta pretty recently and I must say I'm impressed. It looks like a great place to go to get tough programming (and other) questions answered. <br/> So, in order to give it a spin I posted the question <a title="Do you disable SELinux?" href="http://stackoverflow.com/questions/97816/do-you-disable-selinux" target="_blank">Do you disable SELinux?</a> </p> <p>It didn't get nearly as many answers as <a href="http://stackoverflow.com/questions/84556/whats-your-favorite-programmer-cartoon" target="_blank">What's your favorite “programmer” cartoon</a> but I did get mostly good feedback, it seems like the audience on stackoverflow, in general, have seen the positive progress of SELinux and many have chosen to keep it enabled (or even write policies and make it work for them).</p> <p>Good to hear!</p> 2008-09-14T00:00:00-05:00 http://securityblog.org/2008/09/14/selinux-on-ubuntu-part-1 <p>I'm in the process of moving my server from an ancient decrepit Gentoo install to a shiny new Ubuntu Hardy install with SELinux enabled.</p> <!--more--> <p>The policy installed with Ubuntu is fairly limited. It is a very small base policy with a cups module available. This was the result of Ubuntu politics but obviously I wanted something more comprehensive. The first thing I did was grab the reference policy from oss.tresys.com and try to figure out what policies I wanted installed. Reference policy has 259 modules and I didn't want all of them. </p> <p>I took the Gentoo policy ebuild to start, since it is a much smaller policy than Fedora has and I added modules for the services I was going to run. The result (for now) is this:</p> <pre>application = base authlogin = base bootloader = base clock = base consoletype = base corecommands = base corenetwork = base cron = base devices = base dmesg = base domain = base files = base filesystem = base fstools = base getty = base hostname = base hotplug = base init = base iptables = base kernel = base libraries = base locallogin = base logging = base miscfiles = base mls = base mcs = base modutils = base mount = base mta = base netutils = base nscd = base raid = base selinux = base selinuxutil = base ssh = base staff = base storage = base su = base sysadm = base sysnetwork = base terminal = base udev = base unconfined = base userdomain = base usermanage = base unprivuser = base   dovecot = module postfix = module bind = module mysql = module apache = module dpkg = module spamassassin = module ntp = module</pre> <p> </p> <p>This is a relatively small policy, yeilding a 500k policy.23. </p> <p>Then I ran in to my first problem. The SELinux libraries installed on Hardy won't build the most recent reference policy due to a bug that was fixed after Ubuntu's libraries were built. So I had to upgrade my libraries and policy compiler. Since I normally develop on Fedora I assumed I could grab some sort of source deb, update the code and rebuild it. I couldn't figure out how to do that though, all of the source pointers go to the developers repository which looked just like the upstream source. I have no idea how to build debs so I gave up and just built from the selinux userspace git tree. </p> <p>After getting a toolchain I could build the policy on and building and installing the policy I relabeled the filesystem and tried rebooting. Thats when the second problem happened. I couldn't log in via ssh (doh!) and the server is located alot of miles away (like 1000 or something). Good thing the machine has a remote administration console. So I logged in via that and took a look at ps -AZ to see what was going on (I was certain that ssh was running in the wrong context and that is why I couldn't log in, even in permissive). Everything was running in sysadm_t !?! This was pretty baffling to me, I did some sesearch's on the policy (btw, the setools package pulls in the whole thing which requires gtk, tcl, tk, whatever.. too bad there isn't a setools-console package). Well it turns out that if the upstart_init boolean isn't set to true then initrc_t transitions to sysadm_t on shell_exec_t, I have no clue why, very strange. Set the boolean and everything looks good (yay).</p> <p>Now everything is up and running in the right context (well, mostly everything, mysqld_safe, logger and dd (run for klogd apparently) are running in initrc_t, which is effectively unconfined) I'll work on those later.</p> <p>Right now I'm getting tons of denials, most are related to having a tmpfs /var/run I think, also udev is doing all sorts of crazy things (but then again doesn't it always). Hopefully I'll get these taken care of and I'll write another article about the success (assuming I succeed and don't give up <img src='http://securityblog.org/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> )</p> 2008-09-02T00:00:00-05:00 http://securityblog.org/2008/09/02/web-browsers-security-and-google-chrome <p>Securing web browsers has always been a little tricky. With so many web applications available today, including corporate intranet sites, email and so on with confidential or proprietary information it is always a bit troublesome that web browsers essentially run in one security domain. The last thing I want is for a teller at my bank to go to some site that ends up getting bank info from another tab. <!--more--></p> <div class="entry"> <div> <p> There have been several improvements in the web browsing space though. Microsoft Internet Explorer has protected mode but that doesn't use system based access control to enforce separation of internal web pages from external ones, for example. On Linux we've started using nsplugin to load plugins (flash, whatever) into a separate process. This is particularly nice on SELinux systems since we can transition those plugins into a domain that can't do much, such as read files in home directories, access the network, etc. Dan Walsh has a nice writeup about this at <a title="http://danwalsh.livejournal.com/15700.html" href="http://danwalsh.livejournal.com/15700.html" target="_blank">his blog</a> </p> <p> That still doesn't separate sites of differing security domains (my bank, joke site my friend sent in an email, the company sharepoint server, etc) into separate processes that cannot interact with each other. </p> <p> I had a customer once that actually augmented Firefox to be a multi-level browser. This was a Trusted Solaris solution and really didn't address the problem. All of the sites were still inside the same browser process and they had only augmented it to try and keep that data separate. Something that used process and domain separation would be better. If we trusted the web browser to not leak data none of this would be necessary! </p> <p> The best we can hope for is manually separating browsers. I've blogged in the past about using network access controls in SELinux to ensure an “internal” browser can't browse the the internet, and an “internet” browser can't browse into the intranet. This requires user intervention to understand and keep track of multiple browsers, hardly an elegant solution. Surely there is a better way. </p> <p> Now comes Google Chrome, a shiny (haha) new browser that has some great ideas. Google also published an interesting <a title="http://blogoscoped.com/google-chrome/" href="http://blogoscoped.com/google-chrome/" target="_blank">set of comics </a>that describe some of the ideas and features. </p> <p> The ones I found most interesting: Each tab is rendered in a separate process, plugins run in a separate process and a javascript virtual machine. This means tabs shouldn't be able to get data from other tabs (now I don't have to worry about crazy scary Myspace pages reading my bank account number). </p> <p> There are a couple things to worry about, first they claim plugins are poorly written and therefore must have access to all tabs (which is particularly scary given the Flash vulnerabilities as of late). The ideal solution is to have a plugin process per-rendering process, this would keep plugins from interacting with each other and other rendering processes. They claim this is a long term goal, that they would work with plugin writers to make this easier, we can only hope. </p> <p> Second, and much more worrisome is on slide 29, the claim that they know their sandboxing works because they wrote it, wrong! If we trusted the applications to begin with we'd have no need for additional access control. </p> <p> Now all this brings me to my main point. Granted Chrome is only available for Windows at the moment but hopefully it'll be available on Linux before long. And then we might have something interesting to work on. Different security domains for different sites? That would be great. Different domains for plugins? Yes! SELinux enforced sandboxes? </p> <p> So here is the idea: We label sites by dns name or IP and have Chrome execute the rendering processes in different domains. *.tresys.com would run in internal_website_t and not be able to send data to the internet! my bank site would run in bank_website_t and only be able to send data to my banks address. Even if I have some sort of browser or plugin exploit going on it won't matter, only data can be sent to the appropriate place (this is the beauty of mandatory access control, even a broken application can't do anything bad). This should work because Chrome even creates new rendering processes if you jump from one domain to another (It does this today). If I go to facebook and then to myspace in the same tab a new process is created for myspace. I'd like to go so far as to put the javascript vm in another process, since it is executing dynamically generated code, or else we'll have to give the rendering process the ability to execheap, execstack, not a good permission to give something already susceptable to vulnerabilities. </p> <p> What is the net result of this? It is like the manual separation I and others have talked about before but from the user perspective it is seamless. Tabs in the same browser running in different security domains without the users knowledge, seamless mandatory security on web browsing, I can't wait! </p> <p> If this should happen to reach any of the Chrome developers I'd love to talk to you about the possibilites. Combining this browser (which is excellent BTW, I'm using it to write this blog post) with the mandatory separation afforded by SELinux would make an incredibly powerful platform for securing web applications. </p> </div> </div> 2008-05-18T00:00:00-05:00 http://securityblog.org/2008/05/18/security-anti-pattern-mls-for-guards <p>This article was requested, and was a long time coming anyway.</p> <p>I've gone over Multi-Level Security (MLS) a little bit before. It's basically a security policy that is implemented by many trusted operating systems (such as Trusted Solaris) that is hierarchical and inflexible by nature. Specifically Bell-LaPadula (BLP) is used by many operating systems because it reflects the real world security policy used by the government and military. In BLP subjects and objects have a label consisting of a level (Secret, Top Secret, Unclassified, etc) and a set of non-hierarchical categories (US Only, Army, etc).</p> <p>The sensitivies are hierarchical in that a higher sensitivity process labeled top secret can read and write top secret objects but only read unclassified objects. This prevents the ‘downgrade' of classified information. For systems that conform to this kind of policy it makes perfect sense, a multi-level desktop system allows users to keep top secret and unclassified material on the same system but does not allow the release of top secret data to unclassified environments or users. Lower levels can also write to higher levels, in some cases. This may seem bad but considering what the policy is trying to accomplish allowing an unclassified process to write a top secret document doesn't disclose top secret data. The catch is that the unclassified process would never be able to read the document after writing it. This policy is only usable for confidentiality, to prevent information from being released inappropriately. It cannot address integrity or other security goals I have mentioned in other articles.</p> <p>Because traditional trusted operating systems only implemented BLP (and in some rare cases Biba for integrity) the users of such systems (primarily government and military) had to use it even when it wasn't appropriate. One such case is a guard, or cross domain solution (CDS). A CDS is a system that allows two or more networks of differing security properties to be connected to one another. A typical CDS can connect a top secret to a secret network, for example, and allow information from the secret network onto the top secret network but not vice versa. CDS's also do the opposite, allowing a controlled release of information from top secret to secret, or between two coalition networks (Such as Australia and the US). CDS's always have some safety mechanism built in to prevent malicious data, or inappropriate data from going across it (if it didn't it wouldn't be any more useful than a crossover cable between the networks). These safety mechanisms are virus scanners, “dirty word” filters, document disassemblers (for example to take a word document and convert it to plain text or pdf), etc. The type of safety mechanism primarily depends on what kinds of networks the system is connecting.</p> <p>For now we'll talk about the first case, letting information flow from a secret network to a top secret network. Since a BLP system is designed to let information go from secret to top secret already it seems like an obvious fit, right? If the CDS was a very simple system with a process to read incoming data, a virus filter and an outgoing process it seems like a BLP policy would be fine. We are going to call the set of processes that pass data through the system the pipeline.</p> <p>Wrong, there are actually multiple issues here. Because the lower levels would be allowed to write to higher levels, but not read from them we could label the incoming process Unclassified, the middle process Secret and the outgoing process Top Secret. This allows flow from the incoming process to the outgoing process. The main problem here is that since the levels are hierarchical there is nothing that stops the Unclassified process from writing directly to the Top Secret process (oops). Well, people figured this out and thought of a great work-around. Remember those categories? Categories allow reading and writing when the subject dominates (or has a superset) the categories of the object. So you give the incoming process categories that dominate the categories of the middle process but not the outgoing process.</p> <p>So that problem is solved (albeit in an interesting way) but CDS's are never that simple (I mean never). The requirements that are imposed on CDS's specify pesky little things like logging, auditing, monitoring, emergency shutdown, etc. So now our simple CDS needs all processes to be able to talk to a logging system, and a monitoring system must ask the processes for their state and get back a response. So now we have one or more huge processes that can talk to and receive data from every process in the pipeline. That wouldn't be so bad except the functional requirements of every guard I've seen says that those logs have to end up on the high side for consumption, which is obvious, they certainly can't go to the low side because that would be a violation of the security policy. This, of course, allows information to flow through the logging and monitoring process out the other side without going through the set of filters. Sure, the advocates will say the logging and monitoring system is part of the TCB (Trusted Computing Base), the part of the system that is trusted to not do nasty things, but in a system like this do you want such processes to be trusted?</p> <p><img src="http://securityblog.org/images/bad-cds.png" alt="Bad CDS" /><br/> The above (totally professionally done) diagram shows the attack vector that would be used to get data through such a system. Because the logging/monitoring app is allowed to violate the MAC policy it is possible to use it to bypass filters 2, 3 and 4.</p> <p>So basically its impossible to use a BLP policy on a guard and ensure that all data is passed through all filters before it reaches the other side, the policy simply wasn't made for that kind of thing. It has been the standard operating procedure to shoehorn CDS's into that policy for a very long time, however.</p> <p>Before I get into how SELinux helps this I'll quickly cover the other two types of guards I previously mentioned. First the High-to-Low guard. This kind of guard basically allows controlled downgrading of information; it will run filters like a ‘dirty word' filter to ensure nothing that shouldn't be getting downgraded isn't. It may also redact some data. This CDS is a direct violation of the BLP policy, as such the processes essentially have to be MAC Exempt, or not subject to the policy, essentially making the existence of the policy irrelevant, it should be easy to see why this is an inappropriate use of BLP. The second was a CDS between two coalition partners. In this case the BLP policy doesn't even mean anything since there is no high side and low side, merely ‘different' sides.</p> <p>So, those are the reasons why BLP is inappropriate for CDS's, why is SELinux different?</p> <p>SELinux primarily uses type enforcement for policy decisions. Type enforcement allows fine grained policy to be written for all subjects and objects on the system. In the case of CDS's you can literally say incoming process can write to virus scanner (but not read) and virus scanner can write to outgoing process. We call this an assured pipeline. This can be used for any size or type of pipeline, we even have a tool called CDS Framework that lets you visualize the CDS system. But wait, what about all that logging and auditing and monitoring? Simple, since the policy can describe arbitrary relationships between processes we can break that logging and monitoring process up into filter size chunks, then allow each filter to read and write from the logging and monitoring app. The logging and monitoring app can then send its logs through the same pipeline as the data, it will end up on the high side but there is no additional large process you have to trust to allow it to happen. Using type enforcement we can ensure that every single bit of information that comes leaves the guard passed through every filter (we can't, of course guarantee that the filters worked). Since type enforcement is not hierarchical the direction of the CDS doesn't matter, we can do the same thing for High-to-Low that we do for Low-to-High, or even between coalition networks.</p> <p><img src="http://securityblog.org/images/good-cds.png" alt="Good CDS" /><br/> The above diagram shows a possible CDS configuration using type enforcement. It allows for logging and monitoring and simply passes those messages back through the filters to get them to the high side. In this configuration no single part of the pipeline is trusted to violate the policy, and filters can never be bypassed. This policy would be impossible to enforce with BLP.</p> <p>Don't take this to mean that I hate MLS and never think it's useful. I'm not saying it kicks puppies (although it does occasional pee on rugs I'm told). MLS has a time and a place, just like everything else. The point I'm trying to make is that it shouldn't be used if it isn't appropriate, as has been done in the past (and continues to be done today).</p> 2008-04-11T00:00:00-05:00 http://securityblog.org/2008/04/11/is-the-bsd-license-more-liberal-or-conservative-than-the-gpl <p>Recently I was looking around for a piece of software and I thought to myself “I need something with a more liberal license than the GPL”.. Then I thought “Wait, is liberal the right word there? Hrm”…<br/> So what do you guys think?</p> 2008-03-30T00:00:00-05:00 http://securityblog.org/2008/03/30/secure-doesnt-mean-anything <p>No, seriously. I'm not trying to be ironic because the title of my blog is “Brindle on Security”, which I should probably change to something more creative anyway.</p> <p>During my tenure at Gentoo, running the Hardened Gentoo project, the most common question by far was “How do I secure my system?” Warning, this article may contain some flamebait, avoid it if you can't resist flaming back <img src='http://securityblog.org/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> .</p> <p>Eventually we gave up and just pointed people to websites, perhaps this post can serve as that page. The answer was “What do you mean ‘secure' your system?” Security isn't, and can't be, a goal by itself. You need to know what exactly you are trying to protect yourself against, your threat model, as it were.</p> <!--more--> <p>SELinux has the ability to protect against many different threat models. In Hardened Gentoo we also had some complimentary projects that protected against things that SELinux couldn't, such as PaX (kernel level memory execution protection and memory layout randomization) and SSP (userspace level stack smashing protection). Fedora also has comparable technologies such as Exec Shield baked in by default.</p> <p>So I saw a thread recently that said something to the concern of “Why use SELinux, which is security bolted onto Linux when you can use OpenBSD which has security as part of the development process?” It's an interesting question I suppose, if you can decode it. The OpenBSD mantra seems to be develop software correctly in the first place and you don't need additional layers of security. The baffling part is that you'll rarely find an OpenBSD user that actually knows what security OpenBSD actually, tangibly provides.</p> <p>All that said, there are different kinds of security that you might want to implement, and lots of different solutions to attain them.</p> <h2>System Integrity</h2> <p>System integrity is what most people mean when they say “secure my system”. Do you want system integrity? The answer is almost always yes. Some people want very good system integrity and end up using a read only medium, like a livecd or dvd, to run their systems. This, of course, only works if you aren't storing important data on those systems, for things like web front ends to applications servers it might work fine.</p> <p>System integrity is what OpenBSD users mean when they say they have a secure system. They integrate quality control into their development process to ensure that as few bugs as possible get into their code and the result is suppose to be high system integrity.</p> <p>Quality control alone doesn't give you complete system integrity, however. Your kernel can be well coded but that doesn't mean much if other processes running as root are vulnerable. Just take a look at ps and see how many applications are running as root. If any of those services are vulnerable your system may have less integrity than previously thought. The fact is everyone runs third party apps on their UNIX/Linux systems. Most users run Apache, samba, syslog, etc and all have components running as root. Even OpenBSD isn't without vulnerabilities, quality control only goes so far, after that more is necessary.</p> <p>Memory protection techniques can help protect against some of these vulnerabilities. NX support on modern processors prevent some exploits that use bugs to add shellcode to running applications but that won't prevent someone from using code already present in the address space, such as system(). Memory layout randomization only provides stop gap protection since the layout can eventually be brute forced, if the administrator isn't watching very closely.</p> <p>Mandatory access control is a way of addressing the gaps between a well coded kernel and vulnerable third party applications. If Apache shouldn't be able to write to anything in /usr then MAC can prevent that. This, by itself, is a huge win for system integrity since it is generally thought that /usr is the highest integrity part of the system.</p> <p>Now for some explanation. On most systems you can think of integrity as either low or high. High integrity files are files that are system objects. Things in /usr are pretty much all system objects. If a system object gets changed the behavior of the system is changed. A rootkit is going to target these high integrity files, for example. Other examples of high integrity objects are, ofcourse, anything in /boot, /lib, /sbin, /bin, most files in /etc, and so on. User files, on the other hand, are generally low integrity files. Anything in /home is untrusted. User data should never be able to affect the integrity of the system.</p> <p>The integrity of a process is determined simply by where it gets its input. If a process reads user data, or data off of an untrusted network it is considered low integrity. Apache, which reads /home/*/public_html and receives queries from the internet, is low integrity. RPM, which is run by the administrator, reads rpm's downloaded from your vendor (hopefully) and installs files all over the system, is high integrity (this is an assessment of how it operates, not whether it is free of vulnerabilities).</p> <p>Now that you know how to determine the integrity level of objects and processes lets talk about the security policy to maintain system integrity. Biba is a hierarchical integrity policy, similar to Bell LaPadula but, interestingly, the exact opposite. It allows processes to both read and write to objects of the same integrity, no surprises there. Next it allows high integrity processes to write to low integrity objects, but not read them and last it allows low integrity processes to read high integrity objects but not write them.</p> <p><img src="/images/biba.png" title="Biba" alt="Biba" /></p> <p>Though the use of Biba is very limited and has never hit a mainstream operating system it is a very good practice, if implemented in a usable way. The standard SELinux policies implement something between Biba and ‘least privilege', with a nice balance to ensure system integrity without making the system completely unusable. Biba, for example, isn't very flexible. Since processes and objects are simply labeled with their integrity there is no way to make practical changes to the policy. You either fall within the constraints of Biba or you are entirely MAC exempt.</p> <p>The SELinux Apache policy doesn't allow Apache to write to the high integrity files we talked about above (/usr, /lib, /bin, etc) while allowing it to write to its logs, its cache, etc. Since objects in SELinux have fine grained labeling we can restrict access to apache high integrity objects, such as apache modules, the apache configuration and so on. In many ways SELinux lets us constrain applications more than Biba while at the same time making practical exceptions when necessary. This brings me to my next kind of security.</p> <h2>Application and Data Integrity</h2> <p>While system integrity is generally of the utmost importance, since it is the basis on which you can build other security goals, in some cases it is not enough. Sometimes the most important part of a system is the applications it is running, or the data those applications manage.</p> <p>For example, if you are running a database server the most important part of the system quite possibly could be the data in that database. How do you protect that data?</p> <p>We can go back to the mantra of well coded systems with quality control but that, once again, fails when you consider other applications running on the system. Granted you'll need to trust the database server itself with the data, there is no way around that but the other applications that can access the data can be problematic. Generally database files would be owned by a non-root user with the correct permissions set to prevent other applications from accessing them without going through the database server. Of course root applications can bypass all those restrictions.</p> <p>There are multiple ways to protect the data. One way is run only the database server on the system and nothing else. That way there is nothing else to protect the data from. This can work in well controlled environments but there are always going to be apps running, like the system logger and sometimes, particularly on UNIX like systems, there is a tendency to put multiple applications on a single system. There will always be the need for backup apps, log monitors, log rotators, etc. This may be a risk you are willing to take, and that is what threat modeling is all about. If you can accept the risk then your security may already meet your needs.</p> <p>Another way people have tried recently is with hypervisors. Unfortunately the current generation of hypervisors always require a domain 0 or host OS that essentially has full access to the disk, the network interfaces, sometimes the memory, etc. Protecting the integrity of applications within a VM is impossible without first doing so on the host OS, as I pointed out in my <a href="http://securityblog.org/brindle/2008/01/24/why-blu-ray-scares-me/" title="Why Blu-Ray scares me">Blu-ray post</a>.</p> <p>MAC systems are IMHO a superior way to handle application and data integrity. SELinux policies can prevent anyone from accessing the database files aside from the database server itself. You may need the backup service to read the database files directly (unless it is configured to get backups directly from the database server itself) but you can easily make the backup server only able to read files without being able to write them, which is not something you can easily do without MAC.</p> <h2>Pipelines</h2> <p>Another security goal which is often overlooked outside of a small niche of guard architects are pipelines. Guards are systems with specific purposes to transfer data from one side to another, while going through a specific set of applications. In the real world one can envision a proxy server or a virus scanning email server as a guard. The idea is that data coming into a system must go through some number of applications before it is allowed to proceed.</p> <p><img src="/images/pipeline.png" title="pipeline" alt="pipeline" /></p> <p>In this security goal it is desired that any incoming email goes through a virus and spam filter before going on to the user mail directory and ultimately onto the end users system. This may be more of a functional goal than a security goal to some. As a former administrator I understand the security ramifications of unfiltered email getting through to the network. This kind of goal is generally enforced with configuration of the mail system but for some people that is not enough.</p> <p>Pipelines obviously rely on system integrity to protect the layer below the pipeline itself, so those security goals are composed onto one another. An opensource project that my company developed called CDS Framework implements this sort of security goal.</p> <h2>Conclusion</h2> <p>There are other security goals one can implement, these are only examples. The first two are probably the most important for most users. The main thing I want people who read this to take away is that there is no such thing as a ‘secure system' or ‘added on security' or ‘baked in security'. Security by itself doesn't mean anything. Users need to determine their threat model and security goals in order to determine what measures need to be taken in order to protect what they want protected.</p> 2008-01-24T00:00:00-06:00 http://securityblog.org/2008/01/24/why-blu-ray-scares-me <p>Now that Blu-Ray has all but won the HD format war I guess its a little late to post this but oh well, I'll do it anyway.</p> <p>Disclaimer: I am an HDDVD owner but this post is not a result of bitterness about my chosen format losing. The reason I'm posting here about (among others) is the actual reason I chose HDDVD. I also don't want to talk about the pro's and con's of DRM or whether the DRM has been cracked and is accessible via other means. I am going to talk about the intentions of the format producers and what it means to consumers.</p> <!--more--> <p>So, basically the big security problem I have with Blu-Ray is that <a title="BD+" href="http://en.wikipedia.org/wiki/BD%2B" target="_blank">BD+</a> (a BluRay specific DRM mechanism) has some scary provisions to make movie producers happy. Basically the idea behind BD+ is that the movie, decoding, etc is done from within a virtual machine.</p> <p>So the problem with using a virtual machine to protect the data from the person who owns the device is that the host inherently can access and manipulate the virtual machine itself, including the data. This presents a fundamental problem with the idea of protecting the content. So in order to address this the movie producer must be satisfied that the host machine is in a state where the virtual machine is considered safe.</p> <p>This is where BD+ gets scary. It allows movie producers to package arbitrary host executables with the BD+ virtual machine that is run on the player before the virtual machine unencrypts any content. The idea, of course, is that a vulnerable host (that is, a host that allows unauthorized access to the unencrypted content) can be patched in order to close the vulnerability. This has some serious ramifications including, but not limited to, producers being able to rootkit machines (see sony's recent rootkit fiascos), spyware, broken patches that make systems more vulnerable, broken patches that break machines, patches that affect different OS releases differently, etc.</p> <p>I almost wish a producer would create a PS3 patch that bricks a bunch of PS3′s just to show how very very dangerous “features” like this are.</p> <p>So that is one of the features that scared me the most. There are other problems I had that caused me to choose HDDVD such as incomplete specifications for BluRay, fewer features in the original specifications, limits on the layering of the disks and so on. I now have a dilemma about whether to get a BluRay player knowing that, as a consumer, the choices I make validate the behavior of the producers. The most disturbing fact is that the consumers who don't know about these issues have implicitly allowed the format producers and movie producers to build this incredibly anti-consumer system. C'est la vie I suppose.</p> 2007-07-15T00:00:00-05:00 http://securityblog.org/2007/07/15/misunderstanding-unix-security <p>I just got a comment on my post about path based access control that was fairly startling to me. The more I thought about it, though, the more I thought maybe others shared the beliefs so I'm going to respond to it here.</p> <blockquote><p>inode-based security has analogous problems to path-based security. Software opens paths, not inodes, so it very much matters what the permissions are for the file at /etc/shadow or /var/data/mydb, regardless of what the inode happens to be. With an inode-based system, security may go out the window when programs replace or manipulate inodes, as many of them do.</p></blockquote> <p>Software opens paths because paths are the exposed abstraction for userspace applications. Sure it matters what permissions are on /etc/shadow, but those permissions and the access control alike is <strong>always</strong> done at the inode level, as I will demonstrate below. Applications that manipulate inodes have always needed to set security attributes on those inodes, look at passwd source code and you will see that it creates the inode with mode 400 (r--------).</p> <blockquote><p>So, neither AppArmor nor SELinux provide bullet proof security or data integrity, although both may be useful in protecting against some problems.</p></blockquote> <p>This is blatantly wrong, SELinux provides controls to specify precisely how things can be labeled. If my policy does not allow an application that handles confidential information to relabel or create a file with a label that is accessible by other applications there are no circumstances where that application will be able to leak the data. Similarly if an application can't read low-integrity data and write to high-integrity files there are no circumstances where the application can harm the data integrity. I suggest you read some of the papers about SELinux policy analysis and information flow to understand the issues and how SELinux can address them. Many are available at the <a href="http://selinux-symposium.org">SELinux symposium website</a>.</p> <blockquote><p>But arguments like the ones in this blog really make me doubt whether the SELinux people even understand the issues or have much of a notion of how files and security work on real-world UNIX systems.</p></blockquote> <p>As much as I'd like to ignore people using ad hominum attacks there may be others under this impression. Note the following demonstration as a counter example:</p> <pre># ls -al /etc/shadow -r-------- 1 root root 947 2007-06-06 03:40 /etc/shadow</pre> <pre># ln /etc/shadow /tmp/shadow # ls -al /tmp/shadow -r-------- 2 root root 947 2007-06-06 03:40 /tmp/shadow</pre> <pre># chmod 777 /tmp/shadow # ls -al /etc/shadow -rwxrwxrwx 2 root root 947 2007-06-06 03:40 /etc/shadow</pre> <p>It should be clear at this point that the UNIX permissions absolutely do not have anything to do with paths, only with inodes. This is how real-world UNIX systems have always worked, path based mechanisms break that convention and are subject to the issues I've noted in the path based article. The simple fact is that UNIX systems never ever use paths to determine access to anything, access control has always been centered around inodes and permissions set on inodes. Do not think that the existance of paths changes that, these are merely an abstraction to make userspace more useful.</p> <p>The arguments against SELinux by the AppArmor people, and others, are purely functionality based arguments. They want to use paths because paths are easy to understand and paths have conventions that can be reflected in their policy (eg., that passwords are always stored in /etc/shadow and therefore that file should be protected). SELinux provides mechanisms to enforce many different security policies including protecting /etc/shadow and /var/data/mydb.</p> 2007-05-28T00:00:00-05:00 http://securityblog.org/2007/05/28/secure-networking-with-selinux <p>During the last year quite a bit of effort has gone into improving SELinux' networking support, thanks to the great SELinux community. While this support is still evolving it will be very beneficial for people to try it out and give feedback so the final result is useful to more users and meets the security needs of a wider audience. As the network support in SELinux continues to evolve (there are already other ideas being discussed for possible inclusion) I'll try to keep this post updated so that people who find it will have the latest information available.</p> <!--more--> <p>Network support in SELinux means many things. In the old days (“old days” is very relative since it was only a few kernel releases back at this point) SELinux had fine grained network access control by way of many object classes. These object classes were netif (network interfaces), node (network addresses) and a handful of socket object classes (such as tcp_socket, udp_socket, rawip_socket and so on).</p> <p>The SELinux policy directly labeled several kinds of network objects including interfaces (using netifcon), internet nodes (using nodecon) and ports (using portcon). The policy statements looked something like these:</p> <p><code>netifcon eth0 system_u:object_r:external_netif_t system_u:object_r:external_packet_t</code></p> <p><code>nodecon 192.168.1.1 255.255.255.255 system_u:object_r:external_node_t; portcon tcp 21 system_u:object_r:ftp_port_t ;</code></p> <p>These labeled objects could then be given access to with normal SELinux rules:</p> <p><code>allow ftpd_t external_netif_t : netif {tcp_send tcp_recv };</code></p> <p><code>allow ftpd_t external_node_t : node { tcp_send tcp_recv };</code></p> <p><code>allow ftpd_t ftp_port_t : tcp_socket { send_msg recv_msg name_bind };</code></p> <p>These basically gave ftpd_t the ability to bind to port 21, send and receive tcp messages on port 21 and send and receive tcp messages on eth0 (whose ip was 192.168.1.1). These worked fine, the only problem is that they weren't specified in a single rule so they weren't coupled. This means if there was another set of rules that let ftpd_t send and receive dns packets (for name resolution) only on the internal interface they could also send and receive dns packets on the external interface by virtue of the rules above. Note that these access controls can still be used en lieu of the ones I'm going to talk about next by setting the compat_net option in SELinux with echo 1 > /selinux/compat_net.</p> <p>The labeling of these objects was eventually added to libsemanage and could be changed on end systems using the semanage command without modifying policies.</p> <p>During the 2006 SELinux Symposium Developer Summit we discussed ideas on making the network labeling easier to use, more able to support typical network restrictions and most importantly to closely bind the interface, address and port. Fortunately for us netfilter in Linux already supports all these things as well as some additional benefits like connection tracking that can be used to more precisely restrict things that use dynamic ports such as ftp.</p> <p>One may be thinking that the easiest way to handle this is to add a domain specifier to iptables so that one could write a rule that matched the SELinux domain as well as the ports, network interface and addresses to allow only ftp packets to reach ftpd_t. This would have decentralized the SELinux policy, however, by moving part of the decision making out of the SELinux security server and into the iptables policy and subsystem. This is generally undesirable as we'd like to keep a single, centralized, analyzable SELinux policy. That essentially left us with using netfilter and iptables to label packets, which would have SELinux allows rules written to allow or deny access. Lets look at how this might be used:</p> <p><code>iptables -A INPUT -t mangle -p tcp --dport 21 -j SECMARK --selctx system_u:object_r:ftp_packet_t</code></p> <p>This labels packets destined for port 21 as ftp_ packet_t. The SELinux rule that allows ftpd_t send and receive packets of this type is simply:</p> <p><code>allow ftpd_t ftp_packet_t : packet { send recv };</code></p> <p>But this doesn't do anything more than the old network controls did, lets look at something more interesting:</p> <p><code>iptables -A INPUT -t mangle -p tcp --dport 21 -i eth0 -s 192.168.0.1/24 -j SECMARK --selctx system_u:object_r:ftp_packet_t</code></p> <p>This labels only packets on eth0, coming from 192.168.0.1/24 and on tcp port 21 as ftp_packet_t. So this has the advantage of being able to couple anything that netfilter supports together. Another iptables rule such as:</p> <p><code>iptables -A INPUT -t mangle -m state --state RELATED,ESTABLISHED -j CONNSECMARK -restore</code></p> <p>will copy the label for related packets so when an ftp client attempts a file transfer the related port (which is dynamically assigned at the time of the transfer) will receive the same label. This takes advantage of netfilter's connection tracking features to allow ftp to only receive packets related to its connections. This requires no additional policy rules or policy modifications of any kind since the labels are all we are changing.</p> <p>What this brings over netfilter's existing functionality is the ability to specify precisely which domains can access which packets, so it allows you to bring the firewall functionality all the way to the processes rather than just to the machine, which is significant if you have several services of differing security properties running on the same machine. This would, for example, allow you to have an internal Apache instance with access to company confidential data to only be accessible internally and another external Apache instance that serves static web content to the internet.</p> <p>While most people think of network access controls in the terms of firewalls alone this is not the only network support in SELinux. The next kind of SELinux network support is labeled networking.</p> <p>There are two methods of labeling network traffic in SELinux: NetLabel, which is an implementation of CIPSO, and IPSec based labeling. I'm not going to talk about NetLabel because it only supports the MLS portion of the SELinux context and is primarily useful for making SELinux cooperate with legacy trusted operating systems like Trusted HP-UX and Trusted Solaris. IPSec based labeling sends the entire context but currently only works between SELinux systems.</p> <p>As NetLabel is primarily for supporting MLS and legacy trusted systems I'm not going to talk about it, lets instead move to IPSec based labeling.</p> <p>I'm going to assume some knowledge of IPSec here so if you are unfamiliar with some of the terms please consult IPSec documentation. In particular you need to know what SPD's and SA's are and what their role in IPSec is.<br/> The first thing you need is a kernel that supports IPSec labeling. The easiest way (if you are using Red Hat) is to use the current Fedora rawhide kernel or the LSPP kernel. The LSPP kernel is available at <a href="http://people.redhat.com/sgrubb/files/lspp/">http://people.redhat.com/sgrubb/files/lspp/</a>. For the non-Red Hat users in the audience labeled IPSec is also available in the released version of linux-2.6.22.</p> <p>You'll also need an ipsec-tools that is capable of labeling, rawhides or the LSPP version will do here as well. Once you have everything you need installed you can start using labeled IPSec. We'll start with simple labeled SA's.</p> <p>First I have a couple programs that will help test and ensure that everything is working. They are simple a simple client and server that connect, use getpeercon() to return what the context of the network socket is.</p> <p><a href="/src/client.c">client.c</a></p> <p><a href="/src/server.c">server.c</a></p> <p>Build these by linking them against libselinux:</p> <p><code>gcc -o client client.c -lselinux</code></p> <p><code>gcc -o server server.c -lselinux</code></p> <p>First lets try running them without IPSec to see what happens:</p> <p>My test machines are 192.168.147.132 (scarecrow) and 192.168.147.130 (poisonivy), obviously replace with your addresses.</p> <p>After running server on 192.168.147.132 and running client 192.168.147.132 on the other machine the output should look like this:</p> <p><code>[root@poisonivy ~]# ./client 192.168.147.132</code></p> <p><code>getpeercon: Protocol not available Received: Hello, (null) from (null)</code></p> <p><code>[root@scarecrow ~]# ./server</code></p> <p><code>getsockopt: Protocol not available server: got connection from 192.168.147.130, (null)</code></p> <p>getpeercon() returns protocol not available because no labeling was enabled on this connection, you can use the error to determine if you are using a labeled network socket or not.</p> <p>If we make an SA between these 2 machines without specifying a context we'll get the same results:</p> <p><code>[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test </code></p> <p><code>spdflush;</code></p> <p><code>flush; </code></p> <p><code>spdadd 192.168.147.130 192.168.147.132 any</code></p> <p><code> -P in ipsec esp/transport//require; </code></p> <p><code>spdadd 192.168.147.132 192.168.147.130 any</code></p> <p><code> -P out ipsec esp/transport//require;</code></p> <p><code>[root@poisonivy ~]# cat dev/ipsec/setkey.poisonivy.test </code></p> <p><code>spdflush;</code></p> <p><code>flush; </code></p> <p><code>spdadd 192.168.147.132 192.168.147.130 any </code></p> <p><code> -P in ipsec esp/transport//require; </code></p> <p><code>spdadd 192.168.147.130 192.168.147.132 any </code></p> <p><code> -P out ipsec esp/transport//require;</code></p> <p>Then run:</p> <p><code>[root@poisonivy ~]# setkey -f dev/ipsec/setkey.poisonivy.test </code></p> <p><code>[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test</code></p> <p>NOTE: both machines will need to be running racoon in order to create SA's when the connections are attempted.</p> <p>Running server and client the same as before will give the exact same results. You can use setkey -D to see the newly created SA's. Notice that the SA's are not be labeled.</p> <p>If we add a -ctx statement to our setkey files such that:</p> <p><code>[root@scarecrow ~]# cat dev/ipsec/setkey.scarecrow.test </code></p> <p><code>spdflush;</code></p> <p><code>flush; </code></p> <p><code>spdadd 192.168.147.130 192.168.147.132 any</code></p> <p><code> -ctx 1 1 "system_u:object_r:default_t:s0" </code></p> <p><code> -P in ipsec esp/transport//require; </code></p> <p><code>spdadd 192.168.147.132 192.168.147.130 any</code></p> <p><code> -ctx 1 1 "system_u:object_r:default_t:s0" </code></p> <p><code> -P out ipsec esp/transport//require;</code></p> <p>You can use setkey -DP to see the SPD entries on each machine, note the context field in the entries.<br/> Repeat this with the other machines setkey file. Note that you'd never use default_t in a label, this is an example to show what happens. This is _NOT_ the label that will be used to create SA's, this label will be used in a ‘polmatch' rule to see which SPD entries a domain can match to. This will be explained later.</p> <p>Running setkey -f results in an error now:</p> <p><code>[root@scarecrow ~]# setkey -f dev/ipsec/setkey.scarecrow.test </code></p> <p><code>The result of line 8: Permission denied.</code></p> <p><code>The result of line 14: Permission denied.</code></p> <p>Looking for the denial:</p> <p><code>[root@scarecrow ~]# tail /var/log/audit/audit.log | grep AVC</code></p> <p><code>type=AVC msg=audit(1179150979.762:33): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association type=AVC msg=audit(1179150979.895:34): avc: denied { setcontext } for pid=21632 comm="setkey" scontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=association</code></p> <p>This is good, it means that we can protect who sets the labels on IPSec SPD's. For now set permissive mode on both machines and run setkey again, it should now succeed.</p> <p>Run the client and server again and you should see something like this on the client side:</p> <p><code>[root@poisonivy ~]# ./client 192.168.147.132 </code></p> <p><code>Received: Hello, root:system_r:unconfined_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh</code></p> <p>You can use setkey -D to see the newly created SA's and note the context field in each entry.<br/> Hopefully this image conveys how the SA's are labeled, note that each side of the connection has 2 SA's, one incoming and one outgoing with the appropriate labels. The outgoing SA for each system is always the local domain, the incoming SA for each system is always the remote domain.<br/> <img src="/images/ipsec.png" title="labeled ipsec" alt="labeled ipsec" /><br/> I'd like to thank <a title="Chris Ashworth" target="_blank" href="http://smashworth.org">Chris Ashworth</a> for the graphic, it is much simpler than mine and I think gives a better understanding of the labeled tunnels.</p> <p>This demonstrates that the server sees root:system_r:unconfined_t:SystemLow-SystemHigh when it calls getpeercon() and the client sees root:system_r:unconfined_t:-SystemHigh. To show the difference more specifically run the client with a different context using runcon:</p> <p><code>[root@poisonivy ~]# runcon -t httpd_t ./client 192.168.147.132 </code></p> <p><code>Received: Hello, root:system_r:httpd_t:SystemLow-SystemHigh from root:system_r:unconfined_t:-SystemHigh</code></p> <p>Now you can see the server sees httpd_t when it calls getpeercon(). So now we've seen how you can identify the process context on the other side of a connection, but what about the policy?</p> <p>Lets clear out dmesg and setenforce 1; setenforce 0; to clear the AVC and start the process over.</p> <p>First running setkey and then audit2allow -d should show:</p> <p><code>allow unconfined_t default_t:association setcontext;</code></p> <p>This means that unconfined_t (what your shell normally runs as) tried to set the context of an association to default_t. This is expected since we used default_t in our SPD entry. Run dmesg -c to clear the kernel buffer and try to run the server and client (with runcon):</p> <p>Removing the irrelevant rules we should see something like this on the client side:</p> <p><code>allow httpd_t default_t:association polmatch;</code></p> <p>This rule means that the client (running as httpd_t) attempted to match against the SPD entry we added earlier. This is useful because you can use SELinux policy to enforce which SPD entries a domain may match against. For example, if you wanted to have some domains use high quality encryption and let the others use a faster, lower quality encryption you can do that by specifying which SPD types a domain may polmatch against.</p> <p><code>allow httpd_t self:association sendto;</code></p> <p>This is httpd_t sending data to an association labeled httpd_t. This basically just means that it is sending to the association created for it. Note that with the current controls you can not control which domains you are sending to on the other side.</p> <p><code>allow httpd_t unconfined_t:association recvfrom;</code></p> <p>This is the most significant control; it says that we are allowing httpd_t to receive from an association labeled unconfined_t, which is the result of the server running in unconfined_t. This lets you use policy to determine which domains on another machine can send data to which domains on the local machine.</p> <p><code>allow unconfined_t default_t:association polmatch;</code></p> <p>And this is the remote domain (the server) matching against the income SPD entry on this machine. Note that there were 2 SPD entries added, one for outgoing communication and one for incoming communication, both domains have to polmatch the SPD's on the local machine (for outgoing) and the remote machine (for incoming).</p> <p>There should be similar denials on the server side, only reversed so I won't go over those.</p> <p>As you can see you can do a significant amount with this technology, assuming that you control both policies (source and destination) you can be very certain which domains are talking to which domains across machines, similar to the SELinux IPC controls but across a network!</p> <p>For example, one possible application of this technology is to have an ‘internal' and ‘external' browser on employee workstations. The internal browser would run in a domain that is allowed to access internal company web application servers that contain confidential customer information while the external browser can access the internet. This reduces the risk that rogue internet content can compromise your internal data. This kind of separation would be much more difficult (or impossible) without SELinux' advanced networking controls.</p> <p>Using both labeled IPSec and netfilter secmark you can do some pretty amazing things with SELinux networking, and its only going to get better, stay tuned for more information.</p> <p>A special thanks goes out to all the people that worked hard on getting this technology where it is now and the same ones trying to push it even further to have the best secure networking infrastructure around. These people include (in no particular order): James Morris, Venkat Yekkirala, Joy Latten, Paul Moore (who implemented NetLabel), and many others.</p> 2007-05-05T00:00:00-05:00 http://securityblog.org/2007/05/05/dont-disable-selinux <p>A while back I wrote <a target="_blank" href="http://securityblog.org/brindle/2006/05/21/software-not-working-disable-selinux/">a post</a> on companies telling their customers to disable SELinux in order to get applications running and why this is a very bad thing. While I don't see the situation getting better in the near term I did see a <a target="_blank" href="https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/6453">blog posting today from an SAP employee</a> about using SELinux with SAP. This made me happy <img src='http://securityblog.org/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p> <p>Since I don't think his blog software uses trackbacks I'll be contacting him to suggest some changes. Namely he says that SAP would not be able to send SELinux policy modules with their software to customers since it apparently gets installed in many different places.</p> <p>I'd first like to mention to him (and anyone else reading this) that SELinux policy does not care about paths, only types. The policy part of the module can be the same for every SAP customer, specifying the exact interactions between their software and the rest of the system. The file context part of the module is not compiled and can be generated at install time and added to the policy they distribute with the semodule_package command. After installing the module and labeling the SAP related files everything should work the same.</p> <p>Next I'd like to mention that, while this is a noble effort and I'm very happy to see enterprise vendors showing their customers how they can use SELinux, this article essentially tells people to audit2allow the SAP related denials into policy without reviewing exactly what those denials were or whether they were appropriate. My <a target="_blank" href="http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/">status quo encapsulation article</a> is an analysis of this style of policy writing and why it is bad.</p> <p>If a SAP engineer wanted to create a policy for SAP applications that implemented proper security objectives and have that added to the reference policy I'm sure we'd be more than happy to add it in. There are other options though. IBM has been working with my company, <a target="_blank" href="http://www.tresys.com">Tresys</a>, to develop a product, <a target="_blank" href="http://tresys.com/products/razor.html">Razor</a>, that takes generates policy for Websphere and DB2 by using configuration files that are understandable by the administrators of said applications. More information on the technique that Razor uses to create policies is available in a <a target="_blank" href="http://selinux-symposium.org/2006/slides/05-websphere.pdf">case study</a> from the 2006 <a target="_blank" href="http://selinux-symposium.org/">SELinux Symposium</a>. This product can be used to generate policy for all kinds of enterprise applications, including presumably SAP, that implement specific security goals instead of just encapsulating the status quo of the application.</p> <p>All that said, I'm still glad to see some companies taking initiative and trying to work with their customers instead of against them.</p> 2007-04-19T00:00:00-05:00 http://securityblog.org/2007/04/19/selinux-training <p>My employer, Tresys Technology, occasionally hosts an SELinux training class, many of which I've been the teacher for. The course outline and slides are available for free at <a target="_blank" href="http://tresys.com/selinux/selinux-course-outline.html">http://tresys.com/selinux/selinux-course-outline.html</a> but that isn't what this post is about.</p> <p>I've been asked if I think many people would pay to take an online shorter version of the class if it were around $500. I wasn't sure how to answer so I decided to ask the people that read my blog what they think. It would be an 8 hour video or slide version of the course available on the web. If not many people would take the class another option is to have a 1 hour free webinar that talks about how SELinux can be useful to commercial enterprises that IT people could use to learn some basics about what SELinux can do.</p> <p>I'd like some feedback on these ideas but in any case you can come see me teach a tutorial in person at Linux World Expo San Francisco in August.</p> 2006-08-24T00:00:00-05:00 http://securityblog.org/2006/08/24/the-future-of-selinux-or-how-we-are-going-to-take-over-the-world <p>I've been talking to a few people about what SELinux might look like in a few years and the conversations have been fairly stimulating so I'm going to share some of the ideas here.</p> <p>As you (hopefully) know in my day job I work on the <a target="_blank" title="SELinux policy server" href="http://sepolicy-server.sf.net">SELinux policy server</a>, which as far as I know, is the most forward looking SELinux project around. Granted all those forward looking goals aren't published on the site, hopefully we can remedy that at some point.. So alot of this is going to be centered around the policy server, other parts are just on my wishlist.. without further ado lets get started...</p> <!--more--> <p>I think the absolute most important thing that needs to happen is that SELinux needs to become part of the system, not a strap on, not a value add, not an extra burden, it must be part of the system. There are a ton of things that need to happen for that to happen, most of the desires below will, in some way, reflect on this main goal.</p> <p>First and foremost we need complete protection. Its been said many times in the past and its still true. If SELinux desktop deployments are ever going to be entirely secure a security enhanced X server is necessary. Without it even a confined mail client or web browser can use the X protocol to manipulate or otherwise hijack other applications running in X. This isn't something that can be solved any way except by making X an object manager. This work has been done, I personally have run a security enhanced X server for extended periods of time but without a proper integration into upstream and proper deployment by distributions it won't help. In addition to the enhanced X server the window manager must be SELinux aware. This means that the window manager is capable of launching applications in different domains, managing clipboard data and ensuring it doesn't allow information to be leaked from one domain to another without permission and many other things. Once these two things are in place we are well on our way toward SELinux utopia.</p> <p>One of my biggest desires is to use SELinux to its potential and make the root user powerless by default. Ubuntu has started on this path already, making the root user not able to login and forcing users to use sudo to do administrative tasks. This is a disruptive concept that many many people won't like but it must happen. Once the root user is powerless by default SELinux roles are used to manage administrative tasks and grant only what is necessary to each user, which brings me to my next point.</p> <p>Fine grained role management is an absolute must. The SELinux reference policy already has concepts that will allow this to be implemented in the (hopefully) near future. Each policy module should export some sort of role capabilities (not to be confused with Linux or POSIX capabilities) that can be granted by the system administrator. For example, the Apache module should have an interface that, when invoked, gives a role authorization to administer Apache, whatever that means. Once the policy is running on the system the administrator should be able to specify the precise capabilities that any role is able to use. This brings me to my next point.</p> <p>The user management and selinux role and user management must be unified. An administrator should absolutely not need to go to a different application or dialog box to give a user that he just created extra SELinux privileges. SELinux must be a first class citizen of the system. In the user management interface the SELinux options must be present and easily usable. For example, my small company just hired a new junior admin. I want this admin to administer a handful of daemons, including apache. The interface where I create him as a user should have a very obvious way of customizing his roles capabilities (this depends on the fine grained role management). Everything about the system must be unified, which, again, is my main point, SELinux must be part of the system, not an addon.</p> <p>When I want to adjust my firewall settings SELinux settings should be present. We already know that SELinux is capable of much more fine grained network controls, specifically that you can specify specific domains that can access the network in specific ways. The example I want to use here is Firefox. I want my enterprise to enforce that each workstation must have two web browsers, one that is intranet only and one that is internet. This will allow me to prevent any kind of Firefox exploit from touching my internal network. The network management should be able to let me specify that I want two Firefox domains with different network access controls. We'll put two firefox icons on the desktops and SELinux will take care of the rest.</p> <p>We shouldn't just have fine grained access of client sessions though. One of the biggest problems plaguing the Internet is that web servers are notoriously insecure. When a random untrusted user's PHP scripts are allowed to run in the same domain as trusted system scripts there is clearly a problem. Apache should be able to bracket privileges of user and system scripts, or even fine grained bracketing between different classes of users. The most secure and effective way to do this is to execute interpreters per target domain. FastCGI basically does this for DAC already. When a user's script is accessed FastCGI determines if there is already an interpreter running as that UID that can handle the request, if not it will spawn one. We need to take this one step further and make a system like FastCGI spawn interpreters per UID per domain. This would make an enormous difference in the security of webservers and should be the default configuration. Alternatively for people who truly have performance requirements Apache chould use dynamic transitions to bracket privileges, though I don't suggest this as a permanent mode of operation.</p> <p>Speaking of privilege bracketing, it would be very nice for other applications to do this as well. The systems package manager (we'll assume RPM for now) should be able to do a few things. The proper RPM process will have access to do pretty much anything, thats a given. That doesn't mean, for example, that arbitrary scripts that execute as part of the install process should have unlimited access to the system. RPM is already able to execute scriptlets in a different domain so we are partially there. One interesting thing I'd like to see is RPM being able to treat 'trusted' and 'untrusted' packages differently. We'll assume packages coming from the distro are trusted and third party ones are untrusted. An untrusted RPM should be much more restricted on the system, both the scriptlets and the RPM process itself. An untrusted application shouldn't be able to overwrite high integrity binaries or configuration files (think /usr/bin/passwd and /etc/shadow) or label files with high integrity labels (like passwd_exec_t). Firther the scriptlets should not be able to overwrite files on the filesystem or any of the other nasty things scriptlets like to do. This is disruptive as well since there are probably about a million RPM packages around that do seriously questionable things.</p> <p>Since RPM also installs SELinux policy the same bracketing should apply there. Using the policy server one should be able to restrict the kind of policy an untrusted RPM can insert (while still allowing them to insert policy for the application being installed). For example a third party RPM like Opera (hypothetically ofcourse) should be able to install the browser policy but should not be able to add rules that let it (or anything else for that matter) access /etc/shadow. Nor should be allowed to overwrite any system binaries or libraries. A production ready policy server (we are working on this, I promise <img src='http://securityblog.org/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> ) and an effective metapolicy would be necessary for this requirement.</p> <p>Since one of the most critisized aspects of SELinux is its inability to apply fine grained controls to network filesystem this should also be added. This is alot more complicated than it seems at first, the network protocol should be sufficiently protected enough that the file labels sent across can be trusted. The client and server must also agree on an access control policy otherwise unexpected things can result. The client won't be able to subvert the policy on the server side but since many network filesystems are caching the user might not understand why a write succeeds but is reverted when the client flushes its cache to the server. Network security servers like Samba should be able to take advantage of SELinux by applying access controls to the incoming clients.</p> <p>SELinux management, up until now, has been very focused on the policy itself. This isn't how administrators or users think, however. If someone wants to give user bill write access to a file in /usr/local/bin/bills-script he won't think to go to a policy, he'll instinctualy go to either the object itself (/usr/local/bin/bills-script) or to bill in the user manager. Either interface should be able to manage SELinux permissions. Chances are most people aren't going to learn how to write SELinux policy (most people didn't learn how to write sendmail.cf files and look what happened there!). Simple permission assignments like this should be taken care of by the SELinux management tools, and should be transparent (why do they care what needs to be done to give access, they just need it).</p> <p>This solves some problems but most applications written are applications run within an organization which means there are going to be alot of applications running on SELinux systems that no policy developer has ever seen, or ever will. The process of writing a policy for these applications must be made significantly easier. I've <a target="_blank" title="status quo encapsulation article" href="http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/">posted </a>about how bad status quo encapsulation is in the past but at this juncture an application running a status quo style policy is better than it running without one at all. The system should be able to write a policy for the application with very little interaction from the administrator. This will always leave the ability for more savy admins and users to write well thought out policies for their applications but we need an 80% way to write policies that will help the vast majority of people.</p> <p>SETroubleshoot is a very good first step toward a widely usable SELinux but it needs to go even further. More targets need to be written for it so that it understands most denials. If most expected denials can be caught and dealt with the remaining denials may be indicative of an actual problem on the system, like an attack, something that an administrator should be notified of. By eliminating as many false positive denials as possible SELinux auditing could become useful as an early warning system for attempted intrusions and other bad things.</p> <p>One of the most important things that SELinux can do is educate software developers and companies that their software is broken and how they can fix it. I allude to this in another <a target="_blank" title="blog article" href="http://securityblog.org/brindle/2006/05/21/software-not-working-disable-selinux/">blog article</a> but this will be the most help to the most people. If most systems are running SELinux and users tell vendors that disabling it isn't an option that will force them to fix their software for the betterment of all of their users. I hope that this will be one of the most significant impacts SELinux can make on the entire industry for opensource applications, commercial applications and even internal applications.</p> <p>Oh, one more thing, we need a really cool and secure looking framebuffer graphic that is shown during bootup, that way people know we are really secure <img src='http://securityblog.org/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p> 2006-08-20T00:00:00-05:00 http://securityblog.org/2006/08/20/on-apparmor <p>This will be the last thing I write about AppArmor because quite honestly it's a waste of time to constantly refute people and I'd rather work to make security better for everyone <img src='http://securityblog.org/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> .</p> <p>That said, I taught an SELinux tutorial at LWE San Francisco last week, unfortunately my tutorial wasn't one of the ones reviewed by the media, what a shame. During the tutorial I was asked about AppArmor, to which I said they could come up after the tutorial to talk about it, I didn't want to disparage it in front of an audience of 50, I'm a nice guy like that. <img src='http://securityblog.org/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /></p> <p>Then I saw <a title="But our security goes to 11!" target="_blank" href="http://www.bress.net/blog/archives/36-But-our-security-goes-to-11!.html">this article</a>, which has a quite humorous title, which prompted me to go ahead and write up something that I can point to in the future.</p> <!--more--> <p>If you've read <a target="_blank" href="http://securityblog.org/brindle/2006/04/02/top-down-vs-bottom-up-policy-development/">my</a> <a target="_blank" href="http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/">previous</a> <a target="_blank" href="http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/">articles</a> you'll see the great deal of technical problems AppArmor has and I can even add a few such as an incomplete reference validation mechanism, incomplete object model, the fact that it isn't really mandatory access control (and thus not even comparable to SELinux), etc. Those don't seem to affect a large number of people though, decision makers and administrators sort of give me strange looks when I start going into those.</p> <p>So here are some more reasons, slightly less technical but probably much more important to these particular crowds. You see, I was an admin once upon a time and speaking from experience admins are much less likely to take a 'purity' argument seriously, because they know the kind of impure crap that has to happen to get the job done.</p> <p>I think the most important and compelling argument for both of these crowds is one of scalability. AppArmor is very much a 'right now' type of solution. They give you exactly what you see, a security mechanism that will protect some of your applications within a limited threat model, namely only remote intruders and only if they can only exploit 1 application. So, you say that's all you need and AppArmor lets you write "profiles" in 5 minutes? That's great, are you sure it is all you will ever need?</p> <p>With AppArmor there is no room for improvement. The authors were so focused on ease-of-use that they pushed all the simplicity into the model (incidentally this often creates a very complex implementation but that is another point). The model, then, only covers this very limited threat model. You will never be able to secure your infrastructure more than you can today with AppArmor. Your system level applications will never be secured, your users will never be restricted, and your confined applications only haphazardly.</p> <p>SELinux has its roots in research that started around 1992, to build very secure systems on OS's like Distrubuted Trusted Mach (DTMach), which later continued as the Distrubuted Trusted Operating System project. Eventually the Flask architecture comes out of an implementation by the NSA and the University of Utah which is the same architecture that SELinux uses today. When I started working on SELinux 4-5 years ago it was a very very hard thing to use and implement in a distro. The SELinux researchers and developers were very interested in getting the security right, and then simplifying it with tools in userspace, like it should be.</p> <p>So here it is, 2 years after Red Hat first put SELinux on by default in a general purpose distro (oh yea, AppArmor also doesn't come on by default) and the usability of SELinux has leaped lightyears ahead of where it was. The best part is that SELinux will continue to get easier, while keeping its strengths while AppArmor was artificially limited by a broken design.</p> <p>So, that's the background on SELinux. The point of it was to say, SELinux is complete and comprehensive and also very flexible. The SELinux policy lets you basically accomplish any kind of security goals you have. So you can deploy SELinux today using the targeted policy and tweaking where necessary on your system, which requires little SELinux expertise and when you are ready you can secure more and more of your infrastructure, you aren't artificially limited, SELinux scales to any security goals you might come up with anytime in the future.</p> <p>So I believe that is a pretty compelling reason for an Admin, but I'll throw in another bonus reason. AppArmor claims extreme ease of use and Novell is pushing it on their enterprise clients but one important thing they are missing for any enterprise is any kind of network policy management. I'll grant you that SELinux isn't overflowing with network policy management capabilities today but there are several works in progress. Even without the specific network management SELinux has modular policy and local customizations that let you maintain a set of policy modules that you can deploy to your systems while maintaining local customizations on top of those policies at each machine that needs them, already significantly better than any AppArmor offering. My employer, Tresys has a product coming out called <a target="_blank" href="http://www.tresys.com/products/brickwall">Brickwall </a>that has some pretty advanced network management capabilities and obviously my project, the <a target="_blank" href="http://sepolicy-server.sf.net/">policy server</a>, has some crazy capabilities extending even to access control on the policy, so that you can delegate parts of the policy to junior administrators without letting the intent of the policy change.</p> <p>With the scalability and management features of SELinux (and the lack of them in AppArmor) I'd be seriously shocked if an informed administrator chose AppArmor.</p> 2006-07-05T00:00:00-05:00 http://securityblog.org/2006/07/05/selinux-policy-module-primer <p>Its been a while since my last post, I apologize but I have a good reason I promise <img src='http://securityblog.org/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> . I've been busy working on a series of patches to make the SELinux policy compiler and libraries much more stable and robust and to make optional blocks in the base policy work correctly. While the libraries and compiler are fresh on my mind I thought I'd go ahead and write an article on how the SELinux policy modules work.</p> <!--more--> <p>Once upon a time the SELinux policy compiler was a simple creature. It was self-contained and merely translated source rules into the binary policy in a fairly 1:1 fashion. It became apparent that this kind of policy was difficult to use on complicated systems like Linux and conveniences like attributes were added. The compiler was still simple but had the potential of converting one source rule into many rules in the binary. This is about the time I started working on SELinux, back in early 2003. This worked out fine for a while, as long as users had the policy source on their machines in order to do any kind of customizations at all to the policy (including fairly simple things like adding users). Clearly Hardened Gentoo was fine with this since we compile everything from scratch anyway. Red Hat, however, didn't share our sentiment. Soon after Red Hat did their initial integration work in 2004 the need to make modifications to the policy on production machines became clear. The initial extent was small, only users could be added to the policy and Booleans could be made persistent (lasting across reboots). This required much of the policy infrastructure to be factored out into a library called libsepol. The compiler now links statically against libsepol to build up the policydb structure (the structure that the entire policy is stored in) and other applications can link against libsepol to do operations on the binary policy as well. Originally init and load_policy were modified to read a file with users and a file with Boolean settings and apply them to the policy before loading it into the kernel. The customizations specified in these files never were written to the policy on the disk.</p> <p>While this was a useful progression and necessary for Red Hat's integration there were some concerns about mutating the policy in memory before loading it (and never having a copy of the mutated policy on disk to analyze). The initial customizations wouldn't have affected analysis much but there were some concerns of a slippery slope and it couldn't be long before people would want to add rules to the policy without having the source around.</p> <p>At the same time all of this was going on I had started working at Tresys and one of my first projects was to implement loadable policy modules. We went through several different designs and finally ended up with what you see today, for better or worse. The current module implementation has some limitations, some that we plan to address such as interfaces being part of the language, but are now in pretty good working order for the upcoming FC6 and RHEL5 releases. Now that modular systems are going to be deployed in released systems I hope to educate people about what they are and how they work. So, now that all the history is out of the way lets get dirty.</p> <p>All policies are stored in a struct called policydb which is defined in <code>libsepol/include/sepol/policydb/policydb.h</code>. A simplified version of the struct looks like this:</p> <pre>struct policydb { policy_type; /* specifies whether this is a base, module or kernel policy */ symtabs; /* hashtables of symbols including types, classes, roles, etc */ indexes; /* various indexes used during processing and compiling */ /* --- Stuff only in modules (base or module) -- */ name; /* name of module (only used for modules) */ version; /* version of module (only for modules) */ scope_tables; /* tables that tell the scope of each symbol, what optionals * they were declared in or required in */ avrules; /* linked list of rule blocks, one for the global scope of a * module and one for each optional block in the module. Avrule * blocks contain everything that can be in an optional such as * symbol declarations, allow rules, role allows, and conditionals */ /* -- Stuff only in kernel policy -- */ avtab; /* hash table of rules, keyed on source type value, target type * value,class value and rule type (allow, dontaudit, auditallow) */ role_trans; /* role transition rules */ role_allow; /* role allow rules */ /* -- Stuff only in kernel and base -- */ ocontexts; /* other contexts like ports, nodes, initial sids, etc */ genfs; /* genfs contexts like /proc */ }; </pre> <p>So now that the policy format is as clear as mud we can go into some of the specifics. You'll note that, although the module, base and kernel formats are slightly different, they all share the same struct. This was done for simplicity sake since there is significant overlap and code reproduction for multiple structs would have been much harder to maintain.The most notable difference between the modular/base and kernel formats is that they serve a different purpose. The kernel format has an efficient way to look up access vectors (allowed permissions) for any given source, target, class: hash the values and do an O(1) hashtable lookup (for now we'll ignore the version 20 changes). The module format, on the other hand, can't easily look up an access vector. The module format, however, stores something that is much more representative of the original rule that was in the source code (we'll call this the symbolic representation from now on). For example, consider a rule like this in the source:</p> <p><code>allow portage_t { file_type -shadow_t }:file { read getattr lock ioctl };</code></p> <p>This rule says that the domain type portage_t can read, getattr, lock and ioctl all file objects in the file_type attribute (which is all of them) except shadow_t. In the kernel format this rule would expand to a rule for each type in file_type (which is often over 1000) except shadow_t. The purpose for this type of expansion is so that when the kernel security server receives a request for portage_t to, say, etc_t with the file object class and the permission read it can simply hash the value of portage_t , etc_t, file and get the corresponding set of allowed permissions. This is ideal from the enforcement point of view but we needed something different from rules.</p> <p>The modules needed to maintain what the source says, specifically the { file_type -shadow_t } part. This is because from within a module the final meaning of file_type would not be known. No single module has a full picture of the entire policy and therefore no module can determine what the expanded set of rules for this single source rule would be. Further more complex things like subtracting an attribute require us to carefully preserve what the source says, included deprecated syntaxes like * and ~ in the type fields.</p> <p>So, in the modular format a rule is stored individually (and potentially redundantly) in a struct that looks like this:</p> <pre>struct avrule { rule_type; /* the kind of rule, allow, dontaudit, neverallow, etc */ type_set source; /* set of source types */ type_set target; /* set of target types */ class_perm_list; /* linked list of classes and permissions */ } struct type_set { types; /* ebitmap of all types specified */ negset; /* ebitmap of all types negated */ flags; /* whether * or ~ were used */ } </pre> <p>Using these structs we can specify the above rule fairly easily. The source type_set would have only portage_t in the types ebitmap and the target would have file_type in the types and shadow_t in the negset. The class_perm_list preserves all the classes and * and ~ for permissions.</p> <p>The main difference between a kernel policy and a base module is the rules, as shown above, the other fields are mostly the same. A policy module is a subset of a base module in that it cannot have any kind of labeling (such as filesystem or networking). The policy modules also do not support MLS yet so all MLS related stuff (level and category definitions, range transitions and users with mls levels) must be in the base.</p> <p>Hopefully at this point you'll have a good idea what modules are for and how they are different from the policy loaded into the kernel so I'll continue by explaining how it is that modules work their way to becoming a policy that can be loaded into the kernel.</p> <p>First a graphical representation of the linking, the modules are copied into the base policy:<br/> <img src="/images/module-linker.png" alt="module linker" /><br/> I'm not sure how obvious this image is but hopefully it shows the portage symbols (eg., portage types) being copied into the base policy symbol tables (and the type values change since the base will probably have types with the same values as the portage module so the maps are set up to know what value a type had in its module and what the corresponding value is in base). Next the avrule blocks get copied into the base. They are linked into the list of avrule blocks already there. The same thing happens with the apache module. This new base (or linked copy) is then a superset of base and all the modules. All the symbols from the modules have new (unique) values in base so when the rules are copied the new mapped values must be used. There is quite a bit of technical detail about the copying that I'll just skim over here, if anyone is interested let me know and I can write something more in depth later.</p> <p>After all the avrule blocks have been copied to the base the dependency checker is run. Each module declares its symbol dependencies explicitly. This means that if the portage module needs to use file_type and shadow_t (as in the earlier rule) those types and attributes must be explicitly requested in require { } blocks. Note: in reference policy require blocks are not seen in .te files since the interfaces that use symbols always request them before using them. Optional blocks also have require { } blocks to determine whether that optional block will be enabled.</p> <p>The dependency algorithm enables all optional blocks and then loops through them determining if the symbols required by those blocks are satisfied. When the requirements are found to be unsatisfied the block in question is disabled and the loop continues. If a global block (which is the unconditional part of each module) is ever disabled the dependency checker will immediately bail and tell the user that the requirements for that module were not met. The global block in the base module is self contained and may not have any require { } blocks.</p> <p>Once we have decided which blocks are enabled and marked them thusly we are done with the link phase and are ready to send the linked policy to the expander. The expander is fairly simple in theory but in practice a lot of stuff has to be done to ensure the policy is correctly created. When the expander is called two policydb's are passed in, the linked copy and a brand new empty copy. The expansion is done into a fresh policydb for simplicity so that no cruft is left in from the linked copy which has much more information (such as every symbol, whether it turns out to be disabled or not).</p> <p>The expander starts by going through each symbol table and copying over only the symbols that are enabled. The symbols are mapped to new values so that there are no values left unused in the resulting policy which would cause the policy to be bigger with no advantage whatsoever. Once all the enabled symbols are copied over the avrule blocks are looped through, first the rules are expanded from the symbolic representation into the avtab (a hashtable that holds all the rules, keyed on the source type, target type, class value and rule type). The datum of that hashtable is simply a 32 bit bitmap of the allowed permissions. The avrule blocks also hold "additive" symbols, which are symbols that have a list of something in the datum. The additive symbols are attributes (which have a list of types), roles (which have a list of types, and users (which have a list of roles). If the avrule block is enabled the additive symbol datums are OR'd into the main symbol table of the expanded copy. For example, if an avrule block has a line like:</p> <p><code>typeattribute portage_t file_type;</code></p> <p>then portage_t is added to the datum of file_type in the expanded copy. Once all the avrule blocks have been evaluated all the rules and the additive symbols are complete. The expanded copy is now a valid policy loadable by the kernel. One last thing has to be done, the linked copy holds neverallows in the symbolic form. Tthese neverallows are copied into the expanded copy in the same form (and later discarded) and are used to determine if the final expanded policy violates any of these rules. If no neverallow assertions have been violated the hierarchy checker is run. The hierarchy checker is a validation stage introduced for the policy server which enforces the idea that a hierarchal type (like portage_t.merge, the portage type used for merging files onto the filesystem) cannot have more permissions than the parent type (portage_t in this example). I can go into the details and purpose of hierarchal namespaces in another article.</p> <p>After these post-checks are done the policy is ready to be written to disk and loaded into the kernel. The mechanism described here is what happens in libsepol from modules to a kernel policy, in practice libsemanage, the new library that manages policies on FC5 and RHEL5 systems handle all of this and also does some other policy manipulations. I'll can also talk about these another time.</p> <p>So that is how SELinux policy modules work in a nutshell. Hope this helps anyone interested in this particular subject.</p> 2006-05-23T00:00:00-05:00 http://securityblog.org/2006/05/23/trusted-what <p>This is a response to an <a href="http://blogs.sun.com/roller/page/darren?entry=dear_ibm_please_consider_trusted" target="_blank">open letter</a> from Darren Moffat to IBM. While this open letter has very little substance and is almost entirely opinion there are some things I'd like to address.</p> <!--more--> <blockquote><p>Thanks for trying to bring Mandatory Access Control out of its “hiding place” in the military and trying to put it to use where we really need it in health care.</p></blockquote> <p>Why thank you, we in SELinux land have been working on this for quite some time, of course the inclusion of SELinux into a mainstream Linux distribution (enabled by default) was one of the driving forces behind this. Trusted Solaris (and its Trusted cousins) focused on military Mandatory Access Control and therefore were never able to approach the mainstream. You�ll note that there is a difference between the Mandatory Access Control for military and Mandatory Access Control for every one else, I'll address this later.</p> <blockquote><p>However, personally, I don't think SE Linux is the correct solution for this.</p></blockquote> <p>Any particular reason for this? I�d love to hear some actual technical reasons for this opinion, in the mean time I�ll supply some technical reasons why SELinux is the correct solution (at the bottom).</p> <blockquote><p>Why not work with partner, Sun Microsystems, and use a Common Criteria EAL4+ (CAPP, RBACPP and LSPP) certified system: Trusted Solaris</p></blockquote> <p>You mean the end-of-lifed Trusted Solaris? I think anyone who is forward looking probably wants something that will be supported for a while.</p> <blockquote><p>or better yet our up and comming Solaris Trusted Extensions that layers on top of the award winning Solaris 10.</p></blockquote> <p>Solaris Trusted Extensions is in beta, not well tested, not present in any released (and supported) Solaris and also has not been evaluated ( <a href="http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem" target="_blank">http://niap.nist.gov/cc-scheme/vpl/vpl_type.html#operatingsystem</a> ). Solaris 10 is currently under evaluation for CAPP and RBACPP ( <a href="http://niap.nist.gov/cc-scheme/in_evaluation.html#s" target="_blank">http://niap.nist.gov/cc-scheme/in_evaluation.html#s</a> ) and has apparently not started LSPP. SELinux, on the other hand, has been released in at least 2 commercially supported distributions (Red Hat and Engarde), and in several community supported distributions. Red Hat has EAL4+ in CAPP and is currently in evaluation for LSPP and RBACPP. SELinux is pretty far ahead of Solaris and Trusted Extensions with regard to evaluations.</p> <p>There are also some fundamental changes between the Trusted Extensions implementation and Trusted Solaris. Since Trusted Extensions has abandoned fine grained labels in favor of labeled zones it is difficult to specify specific interactions applications running in different zones can have on one another, more on this later. (This is my understanding of Trusted Extensions, please correct me if I'm wrong)</p> <blockquote><p>A solution that is known to work and has been developed and deployed in mission critical environments for over 15 years.</p></blockquote> <p>Except that Trusted Extensions is very different from Trusted Solaris, and once again, there is a difference between military MAC and commercial MAC.</p> <p>Now, aside from the specific responses above here are my more general responses:</p> <p>The main issue here is that the security goals of this project are can not be met by Trusted Extensions. Trusted Solaris isn't an option since its end-of-lifed.</p> <p>Without talking about this project specifically a primary security goal for commercial applications of MAC is integrity rather than confidentiality. Even in the medical industry the applications manage the data, and the data is not organized into hierarchical levels. The applications, therefore, have to be trusted to manage the data correctly. The security goal, then, is to maintain the integrity of the applications. The way this is accomplished in SELinux is to put the application into a protected domain that only authorized applications can access (including over network resources).</p> <p>In a hypothetical multi-tiered architecture the applications would be managed by an agent that is controlled centrally. The applications may have different data or differing levels of access and therefore need to be seperated. Not only does this allow the applications to have different permissions but also prevents the applications from interfering with one another. The agent would have the ability to manage the applications and their configuration files. The applications shouldn't be able to modify their own or other applications configuration files. Additionally unrelated applications on the system should also not be able to compromise the integrity of the applications or the agent.</p> <p>In SELinux the policy could be configured to tightly control the interaction between the agent and the applications. The applications should only able to read their configuration and talk to the backend servers over the network. The applications could be isolated from one another and have specific network resources (e.g., this specific application can talk to this backend database on this interface and this port). The most important part is that both the agent and the applications must be protected from the rest of the system. That means even if someone is able to compromise another service running on the machine the applications (and the data) is protected (short of a kernel exploit).</p> <p>Now, in the context of Trusted Extensions; the agent and applications would have to be in different zones to maintain separation. This leads to problems though since the agent running in one zone would be unable to write application configuration files or otherwise manage the applications. Since zones are course grained and the only way for them to interact with one another is over network sockets this architecture is not possible. One might be tempted to do one of 2 things. The first is to put the agent and the applications in the same zone. This breaks the security goal since application servers can then interfere with the agent and the other applications. There is no way to separate any part of the architecture and you've gained very little (if anything). The second is to put the application servers into zones and leave the agent in the global zone (the one that has access to all zones). This, however, prevents the agent from being confined in any way.</p> <p>This brings up the bigger concern. The global zone is effectively unconstrained. Any service running in it can affect all the other zones. This in itself violates the security goal since the applications (whether they are in their own zones or not) have no integrity assurance. An exploit of any application running in the global zone can affect the applications (and therefore the data).</p> <p>Next, Trusted Solaris has a long lineage in military MAC. For the uninitiated this means MLS (Multi Level Security). The MLS security model closely resembles the actual “real life” policies of the military and therefore was sufficient for their purposes. This security model implements a hierarchal set of levels that represent different levels of confidentiality (think secret, top secret, unclassified, etc). Trusted Extensions builds on this lineage by using zones for course grained sensitivity levels.</p> <p>This, however, does not address the need for integrity. Since the global zone is unconstrained, that is, it is considered ‘trusted' there is no way to make any claims about the integrity of any app running in any zone. With SELinux even ‘trusted' apps are confined to only the privileges they need to do their job. As an example, the passwd command must be ‘trusted' to violate the security model on MLS systems since it needs to read and write ‘up' to the password file. When something is trusted in MLS it has practically no constraints on what it can do, since the policy is so limited and inflexible. In SELinux the passwd command is allowed to write to the password file but it can't, for example, write to user home directories or use raw devices or use the network. This level of granularity for confining trusted applications is necessary to ensure integrity of any application running on the system.</p> <p>Without Trusted Extensions ability to 1) define fine grained access vectors between the applications, and 2) protect the agent from the applications and 3) protect the integrity of the applications, even from ‘trusted' applications it cannot meet the typical security goals of architectures like this.</p> <p>The ability of Type Enforcement to define fine grained access for the entire system and allow controlled interactions between them makes it a very powerful MAC system that can be used in a number of different environments. MLS has a legacy of being used for military/government systems (and will continue use there, as it is useful for that particular environment) but it cannot be applied to most environments outside of the military.</p> 2006-05-21T00:00:00-05:00 http://securityblog.org/2006/05/21/software-not-working-disable-selinux <p>So, this is a break from my normal philosophical theme to talk about a real experience I had this week.</p> <p class="MsoNormal"> Basically I was trying out some software, without saying what it was or who makes it, I thought it might be helpful for the software development I do at work. For those who don't know I work on SELinux libraries and the policy toolchain at work. </p> <p>That said, I downloaded the trial version of the software and got to work. The first time I ran it I got a very obscure error, it had to do with how the app was being run (after installing it according to the instructions included). After figuring out the "correct" way to run it I started it up only to get another (more obscure) error. I emailed the support address found on their page, including strace outputs and a description of what happened with both issues.</p> <p>I got an email from who I originally thought was a low level support staffer who was instructed to say this, but is actually a cofounder of the company. The email read:</p> <blockquote><p>Hi Joshua,</p> <p>I think you may have selinux enabled (FC5 has this by default).</p> <p>If /etc/selinux/config has the line:</p> <p>SELINUX=enforcing</p> <p>then you need to change it to:</p> <p>SELINUX=disabled</p> <p>(or permissive should work, although I've not tried it).</p> <p>Unfortunately, you need to reboot for the changes to take effect.</p> <p>Hope this works for you (if not, please don't hesitate to ask).</p></blockquote> <!--more--> <p> I was a little shocked. I had heard of people being told this by vendors but it never happened to me, until now. My reply, maybe a little terse, said that I couldn't really disable SELinux and use the software to work on SELinux libraries and programs. I got a reply from the other founder of the company, complete with source code snippets and descriptions on what should be happening and speculations that SELinux was somehow causing the problems. At least he said he was willing to learn about SELinux since I claimed that, while my development machine was in permissive mode, it could not be causing the problem.</p> <p>The first bug was pretty obvious to me from the code, I pointed it out in a reply and included a test program to reproduce the problem, on SELinux or not. That didn't solve the more serious problem though, the one I had been unable to work around.</p> <p>The second bug was a bit more concerning. The source code snippet showed the same variable being used for an open() call, and if open() failed it was printed out. The error was printed out fine but strace showed the open call had garbage in it. While the cofounder I was talking to suspected SELinux was somehow mangling the open call I assured him that SELinux does not ever mangle syscalls and only returns permission errors when something is denied. I was now on a mission to find out the real cause.</p> <p>During this discussion I mentioned some details on how SELinux works, and in particular how it is implemented in Fedora Core 5 (the distro I had the issues on). On Fedora Core 5 SELinux uses the targeted policy by default. The targeted policy confines only part of the system, specifically high risk network facing daemons that generally run with lots of unnecessary access (think Apache, sendmail, cups, etc). The vast majority of the time a user will not be affected by SELinux running.</p> <p>Briefly, one minor exception is that Fedora Core 5 made unconfined_t (the unconfined domain that users and other unconfined apps run in) unable to execute the stack, anonymous memory or load libraries with text relocations by default, which is very good. <a target="_blank" href="http://people.redhat.com/drepper/selinux-mem.html">Ulrich Drepper</a> has more information about those permissions. Some 3rd party software is affected by these permissions, for one reason or another. This is not hard to fix without disabling SELinux altogether but some vendors choose to put you at risk rather than do 5 minutes of research.<br/> Back to the issue at hand, the software was not only running in unconfined_t but the system itself was running in permissive (unfortunately this development VM has to be in permissive because I often reload policies that invalidate all the contexts on the system) and therefore it was very unlikely that SELinux was interrupting the software.</p> <p>The subsequent emails were pretty productive, including a link to a new build of the tool that fixed the first problem. After that I tracked down the second problem, there was some memory corruption based on how I was building my binaries (apparently their software didn't like static binaries). This has been reported and I'm sure they'll attend to it, but the point is that it wasn't SELinux' fault at all. If this happened to someone who didn't know better they would have decreased their security for no reason at all.<br/> Now, the point of this article is to talk to vendors and users who are told by their vendors that SELinux is causing problems with their software. SELinux has become the popular thing to pick on, mainly because, it seems, vendors don't understand it and it had a reputation of breaking things back in the FC2 days (when the old strict policy was used and caused many many problems).</p> <p>The fact is that SELinux is a disruptive technology. There will always be people who fight against disruptive technologies, people who like things the way they are and see no need to change. I personally believe this disruptive technology is necessary for the future of computing but that is another topic. The most unfortunate part about the naysayers is that by telling people to disable SELinux they aren't just affecting their app, they are reducing the overall security of the system.</p> <p>Think about it, a vendor telling you to disable SELinux is, in many ways, like telling you to run chmod -R o+rw / on your system decades ago, since those pesky permissions are clearly the cause of problems in their software. I can make no claims about whether the quality of software has increased or decreased over time but I can say disabling your security system to run an app is rarely the right thing to do.</p> <p>So how do you know if it really is SELinux' fault? The main indication is when a denial happens. You can check your audit log or messages file for an AVC (access vector cache) message detailing what the denied access was. Most of the time it isn't difficult to tell whether a denial is related to the application at hand. If the problem can't be explained by lack of permissions to do something (the something for SELinux is much more granular and comprehensive than Linux by itself) it almost certainly isn't SELinux' fault. If it is a permission problem new SELinux advances will allow you to insert required allow rules into your policy if an application truly needs the access without too much effort (see Dan Walsh's blog for this sort of help). If it is SELinux' fault there is a pretty comprehensive list of resolutions at the <a target="_blank" title="Fedora Core 5 SELinux FAQ" href="http://fedora.redhat.com/docs/selinux-faq-fc5/#faq-div-resolving-problems">Fedora Core 5 SELinux FAQ</a>.</p> <p>I believe it goes without saying that if you have a 3rd party application trying to write to /etc/shadow or /dev/mem you should not add that to your policy and should instead contact the vendor about their badly broken software. Likewise, if the application is doing other nasty things like executing anonymous memory mappings (ofcourse JIT compilers have to do this, but a standard application generally shouldn't) you should urge the vendor to fix their software.</p> <p>I suspect as SELinux gets more uptake vendors will be forced to actually look into SELinux and do what is necessary to make their software work with SELinux. This, ofcourse, can include fixing their software or if the access is truly necessary writing policy that is included with the application. This gives the added benefit of letting you, the end user, actually see what the software is doing (if you care) and forces the vendor to evaluate their own software to see what it does. Often times software is developed over a long period of time with many teams of programmers so the current developers may not even know what huge parts of the software do.</p> <p>However, the vendors aren't going to do this until it makes sense from a financial point of view. I suggest making that happen as soon as possible by telling vendors simply "No, I will not disable SELinux". If they want your business they'll start looking at fixing the problems, which is a benefit to everyone including the vendor. A quick web search for "disable selinux" shows many companies (and even opensource projects) which list disabling SELinux as the "solution" to their malfunctioning software. That list includes: <a target="_blank" href="http://www.vmware.com/support/kb/enduser/std_adp.php?p_faqid=1327">VMWare</a>, <a target="_blank" href="http://www.ifolder.com/index.php/HowTo:Configure_iFolder_Enterprise_Server_on_Fedora_Core_4#Disable_SELinux">Novell</a>, <a target="_blank" href="http://solutions.brother.com/linux/sol/printer/linux/selinux.html">Brother printers</a>, <a target="_blank" href="http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.txt">Oracle</a>, <a target="_blank" href="http://sunsolve.sun.com/search/document.do?assetkey=1-25-83248">Sun</a>, <a target="_blank" href="http://kb.atmail.com/view_article.php?num=172">@Mail</a>, <a target="_blank" href="http://www.psoft.net/HSdocumentation/sysadmin/preparing_servers.html#selinux">Positive Software</a>, <a target="_blank" href="http://www.zend.com/support/knowledgebase.php?kbid=123&#038;view_only=1">Zend (PHP)</a>, <a target="_blank" href="http://current.tigris.org/faq.html#t9">Subversion</a>, … the list goes on.</p> <p>So, if you happen to have the misfortune of dealing with a vendor who chooses to put your infrastructure, business or personal machine at risk rather than fixing their software just send them the link for this article, it may help you, them and everyone else that uses their products.</p> 2006-04-19T00:00:00-05:00 http://securityblog.org/2006/04/19/security-anti-pattern-path-based-access-control <p>For those of you who missed my other Security Anti-Pattern <a title="Security Anti-Pattern: Status Quo Encapsulation" target="_blank" href="http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/">post</a>, an anti-pattern is a commonly reinvented bad solution to a problem. There are many of these in security but one that seems to be occurring quite often these days is path based access control, an access control system that use file paths to refer to objects. To the uninitiated this may seem like a good idea at first, hopefully this blog entry will eradicate such beliefs. Apologies in advance for the length of this post.</p> <!--more--> <p><strong>Not all objects are files</strong></p> <p>The most obvious problem with this is that not all objects are files and thus do not have paths. The UNIX credo that everything is a file isn't entirely true. Network resources, processes, some types of IPC, etc are not files and thus do not have paths. Addressing these types of objects with a path based access control system is either not done or not done well. The limitation not to mitigate access on these kinds of objects is a direct result of the path based design.</p> <p><strong>Paths are ambiguous identifiers for files</strong></p> <p>Next, the pathname of any given file can be ambiguous. On most filesystems an inode represents a file and this inode can have any number of names. The inode is not associated with those names, rather the names are entries in a directory; it is these directory entries that refer to the inode. This means that you can refer to an inode in many ways. Since the policy specifies access by path each one of these names can have different permissions granted. The result is that the same subject, the active entity of an access, can have different access to the same object, the target of an access, based on how it is accessed. For example a users shell might only be able to read /etc/hosts but at the same time write to a hard link of that file at /home/user/chroot/etc/hosts. By writing to /home/user/chroot/etc/hosts he is also writing to /etc/hosts, this is clearly wrong. This is analogous to your door being locked when a burglar walks up to it but being unlocked if he walks to it facing backward.</p> <p>Additionally, on some OS's, an inode can be referred to differently when in a chroot, a private namespace, on a bind mount or as a relative path. The result of these is that different objects can be referred to using the same path. For example, if you have a chroot in /var/chroot that has an /etc/shadow file while in the chroot that file has the same path as the /etc/shadow file on the root filesystem. If an application is to be confined to a chroot and needs to access /etc/shadow it will also get access to the real shadow file via the same policy. This is clearly a problem; suppose I own a bright red Corvette, my car key can start my car but because of the way the locks and keys were designed I can also start any other bright red Corvette. Further, an inode can have zero names in the case that it's been unlinked but is still open, or is not accessible in the current namespace. For cases like the path based access control system may not be able to enforce access controls on the object.</p> <p><strong>Path based policy is not analyzable</strong></p> <p>Because the paths to files are ambiguous there is no way to determine what kind of access and interaction can happen by analyzing the policy alone. When analyzing a security policy one must know unambiguously which subjects can access which objects. Without knowing this it is impossible to determine something seemingly simple like 'What processes can access my /etc/shadow file'. While the policy will have rules that say process X can read /etc/shadow it will not be able to determine what other names /etc/shadow can be referred to as. If a hardlink to /etc/shadow exists in /var/chroot/etc/shadow then my policy analysis can't reliably determine which processes can indeed access that object. The result of this is that much of the policy ends up being encoded into the filesystem. This has major disadvantages in that it isn't possible to analyze the policy separate from the filesystem, it may be impossible to analyze it even if you have the filesystem since bind mounts, chroots and namespaces are set up dynamically at runtime and any attempt to analyze the policy on a running system can result in the filesystem changing underneath the analyzer. The point is that with path based access control systems you can't be sure that the policy you are using is actually being enforced the way you intended.</p> <p><strong>Information flow is important</strong></p> <p>The alternative to file based access control is label based access control. In label based access control all objects have a single, unambiguous label that identifies them and allows unambiguous policy to be written for them. Historically label based access control was used with Multi-Level Security systems (MLS) which is a security model primarily for government use. Because MLS systems were used to limit information flow between levels many path based access control advocates claim that all label based access control systems are primarily used for controlling information flow. Information flow is simply the way a piece of information can flow through a system. A simple example of this is that Process A can write to file X. File X can be read by Process B. It is said that there is an information flow from Process A to Process B. Path based access control advocates, then, claim that information flow does not pertain to them, because they aren't trying to make government grade MAC but instead want to simply confine some processes on the system. What they really mean to say is that they aren't interested in confidentiality (e.g., keeping secret data secret) but instead of interested in system integrity. The main point that is being missed is that information flow is as relevant to integrity as it is confidentiality.</p> <p>Consider a service running on a system such as a database. Ideally this database would be considered to be high integrity. The database would need to have its resources including the databases themselves, config files and interfaces to the server protected. A path based access control advocate might say that they simply need to write a policy for the database server to access these resources while preventing anything else from accessing them. This is only half the story, however. To truly know that the database server has high integrity you have to know not only what can directly affect it (by modifying its config files, connecting to it, etc) but also what can indirectly affect it. If an untrusted (low integrity) user can write to a file that a trusted database client can read then the untrusted user can affect the integrity of the database server. To make this more tangible, say a database backup script runs nightly by connecting to the database, locking and querying each and dumping the data to a backup file. This backup script is a trusted (high integrity) user of the database. The backup script has a config file that informs it of which databases to backup. The backup program must write an input file for the database that does the set of queries for each one of those databases. Naturally it writes the input file to /tmp to send to the database server (hypothetical example of course, but we all know there are many applications that do very dumb things like this). Untrusted user has the ability to put a file which he owns where the database backup script would normally put it so that he can modify it before it gets sent to the database server. The information flow here is untrusted user->database backup tmp file-> database backup program->database. This indirect flow is impossible to find in path based access control policies. The 'we don't care about information flow' argument is totally bogus.</p> <p><strong>Shared directories</strong></p> <p>Speaking of /tmp, another problem arises with path based access control on shared directories like this. Namely, since path based access control relies on files to be named a certain thing it can't protect pathnames that it doesn't know about. Many programs write files to /tmp. The inability to limit interactions between programs in /tmp is a major pitfall of path based access control systems. Even the case that an application writes to predictable filenames isn't sufficient. Consider SSH, it writes files to /tmp/ssh-???????. So you can just use a glob to refer to all those right? Well, the problem is that each of those files might be owned by a different user's ssh session. If a user can access their own /tmp/ssh-??????? file, with this policy they can also access anyone else's. Unfortunately such schemes rely on discretionary access control (DAC) or the standard Linux permissions to separate users in shared directories. This is entirely insufficient if you want to make any assurance to the integrity of any application using a shared directory.</p> <p><strong>Directories aren't security equivalence classes</strong></p> <p>In a previous post I talked about equivalence classes. Equivalence classes give us the ability to specify a group of objects which are identical from an access control point of view. Path based access control systems also use equivalence classes to group objects together, unfortunately their grouping mechanism is already used by someone else, the user. Directories on most systems are used for organizational purposes. They group files together that represent similar ideas to the user, not necessarily to the security system. Take /etc for instance. This directory has many files depending on the system, and chances are they aren't equivalent security-wise. The /etc/passwd file is probably more important than the /etc/services file, but even more important is the /etc/profile which could be used to hijack administrator logins. The passwd program needs to be able to write to /etc/passwd but should not be able to touch either /etc/services or /etc/profile. While this is easy to accomplish with path based access control since you can specify a single file consider the converse, a single file in many directories needs to be accessed by an application. If the application needs access to /bin/ping, /usr/sbin/traceroute, /sbin/ifconfig, /usr/sbin/tracepath and /usr/local/bin/ping2 the rules would have to be repeated for every one of them instead of merely labeling them as equivalent; any changes in access would also need to be propagated to them all.</p> <p><strong>User directories</strong></p> <p>User directories are another challenge. Suppose I want my users to be able to download files from the internet into their home directories, but obviously not execute them while being able to execute files that they build themselves. With path based access control this is not possible. The workaround here is to force them to download files into a downloads directory but forcing the user to act a certain way because of a limitation in your access control system negates the 'ease of use' argument that I'll talk about later. With label based access control the browser, running in its own domain, can write files to the home directory and they will get labeled as browser downloaded files while files the user unpacks and builds himself would have different labels. Thus label based access control provides more flexibility, while using directories as equivalence classes, which is employed by path based access control, restricts flexibility.</p> <p><strong>Lack of object tranquility</strong></p> <p>Path based systems also do not allow for object tranquility. That is, when an object is moved or renamed the security attributes of that object change. Why does it make sense for the object to suddenly have different security attributes after being moved? It is still the same object. Lack of object tranquility introduces a load of problems ranging from races and unintended information flow to revocation issues on Linux. For comparison, Linux permissions (the file mode) are always preserved on move or rename, these permissions are associated with the inode and not with the path. I would talk about object tranquility more but a colleague of mine, <a title="Beyond Abstraction" target="_blank" href="http://www.beyondabstraction.net/">Spencer Shimko</a>, already has a good write-up <a title="Subject object tranquility part 1" target="_blank" href="http://www.beyondabstraction.net/2005/10/13/subject-object-tranquility/">here</a> (part 1) and <a title="subject object tranquility part 2" target="_blank" href="http://www.beyondabstraction.net/2005/11/07/subject-object-tranquility-part-2/">here</a> (part 2).</p> <p>Standard Linux DAC has a serious issue in that any application a user runs can change the permissions on files that user owns. For example, the users web browser can make their .gpg directory world readable and DAC is unable to address that. Path based access control has this problem as well. If an application is able to rename a file (or make a new hard link to it) it is essentially changing the permissions on that file, since permissions are determined by the name of the file. Granted this can be addressed by not allowing applications to rename or hard link files but this imposes additional, unnecessary limitations on the users and applications.</p> <p><strong>Binaries aren't processes</strong></p> <p>A common misconception of path based access control advocates is that the binary on the filesystem is the same thing as the process. This is exemplified by the fact that typical policies specify a binary as the subject of a rule. The main problem with this belief is that it doesn't take into consideration who is running the executable before deciding what access it should have. This is very problematic for user applications. If user A and user B both run their mail client in such configurations the mail client has access to both users' mail directories in their home directories. For example, in the AppArmor evolution policy the 'subject' /opt/gnome/bin/evolution-2.4 is given access to read and write /home/*/.evolution/mail/*. Notice that rather than having access to only read the user's email that ran the client the mail client is able to read (and write) all user's email. Once again these types of systems are relying on DAC to separate users. On label based systems the processes run in their own label which is determined both by the label of the subject executing the binary and the label of the binary itself. This means that the evolution process for different users will have different labels and thus will only be able to access the corresponding users home directory. Some path based access control systems address this pitfall by having per-role rules where the binary is still specified as the process but there are per-role rules, meaning each role can have access to only its own files, such systems still suffer from the other disadvantages.</p> <p><strong>New files and security attributes</strong></p> <p>One ease of use claim for path based systems is that the files are always created with the appropriate security attributes since they are based on the name of a file. This is problematic for two reasons. Remember the web browser download example earlier? Path based systems can't differentiate between files downloaded by the browser and files put there by the user (without changing the user's behavior patterns). Second, and more important from a security perspective, is that you don't want a file getting privileged security attributes if an inappropriate process creates the file. Consider the database race example. This could occur because the name of the file in /tmp was the security attribute supplied to the backup script. Similarly, if a user has the ability to create a /etc/shadow file that file should not be accessible by login, ssh or anything else. It is a major security problem when applications can create objects with permissions or privileges beyond those granted to the original application, if not explicitly allowed to.</p> <p><strong>Ease of use arguments are bogus</strong></p> <p>Finally, most path based access control advocates claim that the main advantage of their system is ease of use. At first this can seem reasonable. Yes, UNIX administrators are already familiar with pathnames, it's very tempting to want to use pathnames for security, but it's a fools errand, because pathnames don't give you the right tool for the job.<br/> Being easy doesn't make it right. And ironically, when the pathname-based solutions attempt to make it right, it gets less and less easy. For example I once talked to an author of a privately used path based access control system and I asked how they handled the /tmp issue. Their solution was to patch all their apps to write to predictable filenames and use their access control system to prevent those apps from reading/writing to filenames that didn't match the pattern. I was dumbfounded. How can one claim a usable system when their apps have to be changed to work around limitations? Obviously this doesn't scale. Another example of this sort of workaround is from Crispen Cowan in a <a title="Immunix defcon presentation" target="_blank" href="http://immunix.com/~crispin/immunix_defcon_issa_03_02.ppt">presentation</a> claiming that an easy way to restrict individual users is to hard link /bin/bash to /bin/fubash, write a restrictive policy for /bin/fubash and set /bin/fubash as the login shell of the restricted user. Without even going into how incredibly easy this is to bypass, this is a very awkward and unscalable workaround that in my opinion isn't at all easy to use or understand.</p> <p><strong> Convinced?</strong></p> <p>There are many issues with using path names in access control systems. While the inability to unambiguously determine the access between a subject and an object is a fundamental flaw there are also numerous technical and usability pitfalls such as shared directories being unusable, home directories being difficult to isolate and the inability to analyze the policy. I hope this article has helped to convince the unbelievers out there that using paths in access control systems is indeed a very bad idea.</p> <p>Note: I've deliberately chosen not to go into detail about specific OS or MAC implementations but instead make this a general article about the use of path names in access control systems. Aside from some minor examples this should apply to most implementations. There are other resources about the specific issues with path names in certain OS's, probably mostly mailing lists.</p> 2006-04-02T00:00:00-06:00 http://securityblog.org/2006/04/02/top-down-vs-bottom-up-policy-development <p>I'll be the first to say I'm not a policy developer. The process of actually writing policy is not at all interesting to me, fortunately for me there are people like Chris PeBenito, Russell Coker, et al that seem to enjoy this. I am interested, however, in <em>how</em> policies are developed.</p> <p>There seem to be two schools of thought on this subject: top-down policy development and bottom-up. Top-down policy development is very similar to status quo encapsulation, which I talked about in a previous post, in that it basically means you take a running system and look at it top-down, in its entirety, and develop a policy based on that perspective. Bottom-up policy development, which is historically what SELinux has done, is the opposite; you create policies for individual applications running on a system until the sum of those policies meets the security goals of the system. I'll try to talk about the advantages and issues with each of these.</p> <!--more--> <p>Many proponents of access control systems like grsecurity seem to favor top-down development. This is encouraged by "full-system learning" mode which creates a status-quo encapsulation style policy for the entire system. For information on status-quo encapsulation see my previous post. The advocates of this method believe that the only way to create a policy for a particular configuration is to do it on that system. This is a reasonable belief, for example it might be popular to connect allow Apache to execute CGI scripts but if that isn't how the system is question is configured why should that be part of the policy? The problem is that it makes a fragile, rigid policy. If the system changes configuration the entire system must be re-profiled to see what is different, this incurs the additional issue of developing a policy on a system that is not in a known good state while re-profiling. One change in configuration can propagate changes to the entire system so trying to modify the system policy manually may be difficult or impossible. The policies are also very complex. Most system administrators and software developers would probably have a hard time looking at an entire running system and know what's going on, even fewer would be able to discern what <em>is</em> going on from what <em>should</em> be going on. Users complicate the matter quite a bit. Since it is hard to profile user behavior the policies are either far too complicated or unusable, or both. Adding users to the system could be problematic since the policy is inflexible and won't have rules that are applicable to new user home directories and so on. Like status-quo encapsulation this type of policy development lacks specific security goals, and only tries to keep the system running like it currently is.</p> <p>In SELinux we take a different approach, bottom-up if you will. The <a target="_blank" title="SELinux Reference Policy" href="http://serefpolicy.sourceforge.net/">SELinux reference policy</a> has pre-written policies for many applications - 177 at the time of this writing. The policies are written and analyzed by security professionals and unexpected behavior is tracked down for the cause. If it turns out the permission was unnecessary for normal application usage the permission can be <em>dontaudit</em>ed instead of <em>allow</em>ed. This is only possible if the policy development and analysis is done on a per-application basis where interactions with other applications as well as all resources used by that application can be studied and analyzed in detail. When application configurations change the effects can be observed and added to the affected application policies without disturbing the rest of the system. The Apache example earlier is a good example. Since the ability to execute CGI scripts is a common configuration the Apache policy has the rules required to do so. If this permission isn't necessary on a system the permissions can easily be tracked down in the Apache policy and removed. Better yet, policies that support multiple configurations can use conditional SELinux policy. In this case if the permission is not required the admin need only toggle the httpd_enable_cgi boolean and the permissions are no longer active on the system.</p> <p>Even when applications don't yet have policies the end user should be much more able to profile a single application and write a policy for it rather than worrying about what every single thing on the machine is doing. Other systems like grsecurity and Apparmor allow per-application policy development, however without a strong foundation to stand on (the system policy) writing an application policy may be moot. Apparmor comes with many application policies - 80 at the time of this writing, but fail to provide the foundation. For example there is no policy for /bin/init, the first app to load on the system and the one that loads everything else. How can one trust the policy limiting an application if the application that loaded it has no restrictions? It is impossible to tell how an application may be affected by other applications if there isn't a policy restricting the init system, X or login. Apparmor is actually designed for application policies only. This severe limitation in its implementation makes it unable to implement many security models. Unfortunately this was a design decision in the mechanism itself, rather than building a general mechanism and making the policies flexible enough to implement this limited access control or if the user chooses, something more complex.</p> <p>On the other hand, grsecurity provides no pre-written policies and leaves it up to the end user to develop/generate the entire thing. This is even encouraged by the main grsecurity developer. A user is free to write a grsecurity policy bottom up but that is a major undertaking. The SELinux policies have years of development in them and are being worked on every day, I have doubts that a single person has ever written a grsecurity policy in this way.</p> <p>Policy writing is hard. Analyzing thousands of accesses by hundreds of applications on modern systems makes the task far harder if a good foundation and reference policies aren't provided. Top down policy development can fail in many ways and in the end provide <em>less</em> security than more lenient pre-written policies. Additionally providing application policies but ignoring the rest of the system can give a false sense of security and leave many attack vectors open. Bottom-up policy development allows one to be very specific about what their security goals are, and create a policy that meets those exact goals. It also provides a flexible way to handle changes in system configuration.</p> <p>My next post may take a while longer than this one as it requires quite a bit of research. Hopefully, unless I get distracted and write something else, it will be about common security models that have been used and what their advantages and disadvantages are, stay tuned.</p> 2006-03-25T00:00:00-06:00 http://securityblog.org/2006/03/25/security-anti-pattern-status-quo-encapsulation <p>First a clarification: in my last post I said that least privilege is the ultimate goal of most MAC advocates but that isn't entirely true, I accidentally ignored a large portion of MAC advocates (mostly those that predate me!). There are several different models which are commonly implemented and thought to be correct. In the government industry that model is Multi Level Security (MLS) and is in no way least privilege, but that is another topic altogether. In the civilian sector status quo encapsulation is a popular model to implement, which is what I'll be talking about today.</p> <!--more--> <p>An Anti-Pattern is a commonly reinvented bad solution to a problem. In security there are lots of these, <a target="_blank" title="The Six Dumbest Ideas in Computer Security" href="http://www.ranum.com/security/computer_security/editorials/dumb/">The Six Dumbest Ideas in Computer Security</a> outlines several that are fairly common but I'm going to go into detail about one in particular that several semi-popular security mechanisms adopt. Status Quo encapsulation is a phrase I started using a while back (I've never seen it used elsewhere, in fact a Google search for “Status quo encapsulation” gives zero results now. It basically means that you are taking a system and using a security mechanism to encapsulate what the system is doing. Security mechanisms such as AppArmor and grsecurity that tout ease of use ‘learning mode'-style policy writing are encouraging this way of writing policy and in many ways giving false impressions about the level of security awarded by such systems.</p></p> <p>There are several problems with this. First, like I said in my last post, applications aren't engineered with security in mind. Merely taking the accesses that an application attempts and enumerating them in a security policy will not necessarily give you a useful policy. In some applications these are poor architectural decisions. For example, Exim, A popular mail transport agent (smtp server) runs as a monolithic process that gives the same process access to both the smtp network port and the mail directory in user homes. This means that if a vulnerability exists an attacker can directly access your users mail, no privilege escalation or further attacks necessary. Sometimes the implementation decisions are poor. For example it isn't uncommon for administrators to use something like mod_auth_shadow to allow apache clients to authenticate using their system password. While this might seem like a good idea, centralized authentication and minimizing user passwords, etc, the implementation allows the apache process to directly read the /etc/shadow file. So if there is a vulnerability in Apache, or more likely a vulnerability in any web application running on Apache the attacker will have your system's entire shadow file. Strictly speaking no access control policy can mitigate problems like these. Application developers and system administrators alike must be aware of architectural and implementation decisions being made in order to have any hope of having a secure system. In security models that encapsulate what the system already does these problems are hidden behind a security policy that doesn't provide protection from these attack vectors.</p></p> <p>The second problem is that the so called ‘learning mode' policies can't be written while the system is idle and disconnected from networks (and untrusted users). The policies can't represent what kind of interactions will be present on the system at production time without writing the policies on machines in production. The most obvious problem here is that the policies are being written on a system that is not in a known good state. A short story to qualify the problem: back in my IT days during college the guys who did Windows installs on workstations would do a stock install of Windows while the machine was connected to the network and then install service packs, virus scanners, etc afterwards. There was an RPC worm on windows (can't remember which one) that would infect the machines before they were even booted up the first time, the machines were never in a known good state and were unable to even have a virus scanner installed before they had been exploited. The parallel in security policies is that once the machine is connected to the network and exposed to untrusted users there is no way of knowing whether the machine has already been exploited before the security policy is active. Without inspecting the policy closely, which is very difficult on such complex systems, the security policy ends up hiding the exploit and any access that the exploit caused outside of the normal system access. Even worse, the policy will continue to allow such exploits even after becoming active.</p></p> <p>The last problem I'm going to talk about today has ramifications both in the security of the system and the functionality. Without static analysis of the system, which is basically automated or otherwise analysis of the source code, it is impossible to see what interactions are possible. Status quo encapsulation only shows what access <em>is</em> done on the running system but ignores the possible access. Functionally it is very difficult to enumerate everything that an application might do while running. I've heard more than one person complain that they are unable to access some folders in their mailbox after using learning mode to write a policy. Why is this? While they were in learning mode they accessed only some of their mail folders. Once the policy was done the folders they had not accessed were inaccessible because the policy didn't know about them. This is a very common problem since exercising the full range of possible access on a system is difficult and error prone (accidentally accessing too much, etc). The only solution is to manually inspect and fix the policies but this loses the only benefit of such systems, ease of use, while retaining all of the downfalls. The security ramifications are closely related but often ignored. Most applications have error paths which aren't often exercised in a normally running system. Some of these error paths are security related. Consider an app which fires off a warning to syslog or tries to email the admin when something bad happens, like an exploit attempt. If these error paths were not exercised during policy learning the admin may never receive the warning. While not as serious as the prior issues it is still important to recognize deficiencies like these.</p></p> <p>As I mentioned before there are many different security models that may fit your needs. Probably one of the most important today is the SELinux targeted policy which specifically targets network daemons and lets local users do whatever they want. This model has a specific goal of confining applications that are exposed to untrusted network resources, and preventing them from harming the rest of the system. It is a lightweight model in that most of the system can run relatively unaffected. Status quo encapsulation, however, is essentially the security model for people who don't know or don't have specific security goals and instead want to rely on their system already being correctly configured and secure and use MAC as a stopgap solution to prevent additional access from being granted. This lack of real security goals in addition to the issues outlined above make this type of model and the mechanisms that implement and encourage them harmful for security.</p> 2006-03-23T00:00:00-06:00 http://securityblog.org/2006/03/23/welcome-to-brindle-on-security <p>I'll start this blog by introducing myself. My name is Joshua Brindle and I've been working on security software and such for a while. About 4 years ago I started <a target="_blank" href="http://hardened.gentoo.org">Hardened Gentoo</a> which exposed both myself and many users to modern security systems available for Linux. This project has, in many ways, led me up to where I am today in my career and otherwise.</p> <p>Today I work at <a target="_blank" href="http://www.tresys.com">Tresys Technology</a> on research and development on security systems. My main project is the <a target="_blank" href="http://sepolicy-server.sf.net">SELinux Policy Server</a>, which is an opensource project working on policy management and policy access control for SELinux but I also help out with various other projects around the company.</p> <p>While I don't have the 20+ years of experience that some of my peers and coworkers have I do believe that I have some unique insights that I haven't seen published or otherwise so I'd like to take advantage of the so called “blogosphere” to share them.</p> <p>Hopefully, with the help of this and other blogs, we can help make security more prevalent outside of the security industry. Large strides have been made in this respect in the last year, especially the introduction of SELinux into a mainstream, general purpose operating system (Red Hat Enterprise Linux 4). This blog will be more focused on security philosophy and theory rather than the practical and howto style posts of other blogs, such as <a target="_blank" href="http://danwalsh.livejournal.com/">Dan Walsh's</a>.</p> <p>That said, I invite requests for specific subjects in posts and I'll try to facilitate them if I'm able so keep reading and watch out for my first post, “The Myth of Least Privilege”</p> 2006-03-23T00:00:00-06:00 http://securityblog.org/2006/03/23/the-myth-of-least-privilege-or-why-we-love-equivalence-classes <p>Just about any Mandatory Access Control (MAC) advocate will tell you that their ultimate security goal is least privilege. Least privilege has become a metaphorical holy grail in the security industry. Least privilege, in its unadulterated form is giving each user, process and so on the exact access it needs and no more.</p> <!--more--> <p>The problem with the idea that this is achievable is that modern systems are very complex. Every application would practically have a catalog of objects that it needs to access, particularly when you get onto the desktop. Every library, man page, binary, configuration file and user file would have to be explicitly granted access. This brings up some obvious problems, particularly the amount of rules that would be required on modern machines but also more subtle ones; for instance, files that are not known, or in existence, at the time of the policy creation. Shared resources are an issue as well as user home directories and temporary files. A user's mail client obviously can be restricted to a user's mail directory and be restricted from the rest of the user's files but a word processor needs practically free reign in the user's home directory, with the obvious exception of private data like ssh and gpg keys. Since a policy writer doesn't know what files a user would open with their word processor it must essentially run with the users normal privileges, which makes it able to access anything the user can, clearly not least privilege. Users, especially on desktops, tend to do very unexpected things which adds more difficulty to the equation.</p> <p>The argument could be made that non-networked applications need not run with their own privilege set but given the complexity of current applications even word processors are susceptible to malicious data that could exploit the user's privileges, particularly in the information rich world we now live in.</p> <p>Another problem is that modern software is often not designed with security in mind. There are hundreds of examples of applications which ask for more access than they need. Many of these applications even work fine without the access but request it anyway. For examples of this look at all the dontaudit rules in the SELinux policy. Without control of all the software on the system we are destined to put up with these least privilege violations. Just using open source software is probably not enough due to the amount of effort and time to clean up the issues (and maintain patchsets when upstream authors aren't compelled to care about said issues)</p> <p>On embedded systems with very small kernels and little software least privilege might not be difficult, particularly when a single company or person controls the source code in its entirety. Systems like these generally don't have users either. This eliminates the complexity and the unexpected behavior of users and thus makes least privilege much easier but general purpose computing remains a problem.</p> <p>The real world solution to this problem is to use equivalence classes on subjects and objects. It doesn't really harm the security of a system to treat all the libraries in /usr/lib the same. Any application that needs to read libraries can be allowed to read all the libraries on the system while still being confined to the resources it needs elsewhere. Even if the application loads a library that it shouldn't, the application will still be confined to the resources that it's intended to use. Other objects can be grouped together as an equivalence class as well. Most binaries in /bin and /usr/bin will actually not run with more or less permissions than the user. For example, trying to give /bin/ls a different permission set than the user running it would mostly be unproductive. Common UNIX commands such as cp, mv, ln, ls, and so on should be treated no differently than the user running them. These equivalence classes make mandatory access control easier to implement and policies much easier to write but using equivalence classes is clearly a conflict with least privilege.</p> <p>Least privilege on modern systems would result in an unwieldy number of rules and would likely cause many problems with applications not being able to access the resources they need. Experience has shown us that users also become startled when things they are accustomed to doing suddenly don't work (such as setting system passwords via apache!). Equivalence classes, such as types in SELinux, provide a layer of abstraction that makes strong security far more viable at the cost of more privilege than absolutely necessary. You needn't worry though, equivalence classes can be as general or specific as necessary and the security policy treats the resources as equivalents at your discretion. The bottom line is that unless your entire system has 5000 lines of code you don't really want least privilege. There are many appropriate (and inappropriate!) security models depending on your system architecture and choosing one is the most important step toward securing the system. I plan on writing about choosing security models in the future so keep your eyes out for that.</p>