Submitted by “Who’s afraid of SELinux? Well, if you are, you shouldn’t be! Thanks to the introduction of new GUI tools, customizing your system’s protection by creating new policy modules is easier than ever. In this article, Dan Walsh gently walks you through the policy module creation process.”
Its not so much that people are afraid.
Its because so few distributions include even basic support for it out-of-the box.
You pretty much need RHEL, Fedora, or simular to get decent support.
This should definitely change, however. Until they do, MS bloggers will keep expelling their FUD about Windows security v.s. *nix.
Just remind them that the NSA wrote SELinux. Microsoft wrote Windows.
Yes, I know that but it is irrelevant to the point I was trying to covey.
Which was?
That is has nothing to do with who wrote it, but to do with the level of decent support across a broader base of distributions.
That doesn’t really wash with me. This seemingly endless blabber that all things Linux are more secure than all things Microsoft has been shown to be wrong time and time again. That doesn’t mean the reverse is true either.
Take a look at the security analysis and patch levels and you’ll see that even though Microsoft do have critical patches, so does Linux, Solaris, MacOS and so on.
The suggestion that the NSA “wrote” SELinux doesn’t imply that it’s secure. Security comes through proof. I’m sure all the pro-Linux, anti-Microsoft chaps will stand up right about now and proclaim that Microsoft has a very poor record.. this is true, I wouldn’t disagree with that.
What I would disagree with is, is the implication that an NSA born Linux is secure, just because, and that somehow Microsoft’s poor record gives SELinux the gold star award for security.
Edited 2007-08-22 00:33
That doesn’t really wash with me. This seemingly endless blabber that all things Linux are more secure than all things Microsoft has been shown to be wrong time and time again. That doesn’t mean the reverse is true either.
Well, how about the fact that Linux has achieved the highest security certification level available to commercial OS’s – a level only achieved by Sun’s Trusted Solaris (at least as popular OS’s are concerned). (I believe it’s RHEL4 that made it.)
That’s more than Microsoft can say, and it was possible because of the NSA’s contribution of the SELinux code to the Linux Kernel.
It’s also not something that’s merely pro-Linux.
Linux is more secure than windows cuz blah blah blah lies blah blah lies blah…
Ok, maybe you are just misinformed!
http://www.commoncriteriaportal.org/public/consumer/index.php
Red Hat Enterprise Linux Version 5 running on IBM Hardware
EAL4+ (Certified: 7 June 2007)
http://www.commoncriteriaportal.org/public/files/epfiles/st_vid1012…
Microsoft Windows 2003/XP with x64 Hardware
EAL4+ (Certified: 18 September 2006)
http://www.commoncriteriaportal.org/public/files/epfiles/ST_VID1015…
(Edit: RHEL4 has the same EAL4+ certification.
+ More on levels and what they need here:
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level)
Edited 2007-08-22 03:31
Except that RHEL 5 has EAL4+ for Labeled Security Protection Profile (LSPP), Controlled Access Protection Profile (CAPP), and Role-Based Access Control Protection Profile (RBAC). The documents you linked to show that Windows only has EAL4+ with CAPP. It does not have any of the other protection mechanisms which is what is really important. The only other consumer OS to meet that higher lever of certification is Trusted Solaris.
As far as Windows getting certified in September and RHEL 5 being certified in June, RHEL 5 wasn’t released until March. XP Was released in 2001 and 2003 was released in 2002. 3 months vs 5 and 3 years is a big difference.
…Well, how about the fact that Linux has achieved the highest security certification level available to commercial OS’s…
The parent claimed that only Linux and Solaris had that certification level, which was false and I cleared that up. They both have the certification level of EAL4+, details may vary though.
As far as Windows getting certified in September and RHEL 5 being certified in June, RHEL 5 wasn’t released until March. XP Was released in 2001 and 2003 was released in 2002. 3 months vs 5 and 3 years is a big difference.
I never compared the dates, I just noted them as it was in the charts.
Obviously Linux got certified faster.
The parent claimed that only Linux and Solaris had that certification level, which was false and I cleared that up. They both have the certification level of EAL4+, details may vary though
Parent claimed:
the fact that Linux has achieved the highest security certification level available to commercial OS’s – a level only achieved by Sun’s Trusted Solaris
Which was shown to be true. The CC system of certification is very complex; and EAL level by itself is not the sole judge of certification level. Thus the details do matter.
“Linux is more secure than windows cuz blah blah blah lies blah blah lies blah… “
Well, technically EAL4+ is the certification for the level of assurance that the technical features are implemented correctly.
The protection profile is the actual set of security features evaluated, and as of right now the protection profiles that RHEL 5 is EAL4+ certified for are:
Controlled Access Protection Profile, Version 1.d
Labeled Security Protection Profile, Version 1.b
Role Based Access Control Protection Profile Version 1.0 (Archived)
This is roughly TCSEC B1 level security and the primary facilitator for Labeled and Role Protection is SELinux’s MAC model.
Windows, while also EAL 4+, is only certified for the CAP Profile which is essentially TCSEC C2.
While NT 6 (Vista and Windows Server 2008) introduce Mandatory Integrity Control, this is not the same thing as a full MAC model (as MIC only enforces mandatory restrictions on modification of objects, not access to them). With the extension of the SACL on objects in NT 6, I wouldn’t be surprised to see a full MAC model in the next release.
It’s also interesting to take note of the configuration of the systems submitted for eval as those are the only components covered by the EAL. So, for example, Windows is EAL4+ certified for the CAP profile, including all its components, whereas RHEL isn’t certified EAL for any profile if the configuration includes X (e.g. a graphical/workstation workload). This is where comparing the two becomes increasingly difficult, because one may be evaluated to support more workloads with certain features, while the other has more features but is limited in what workloads are covered.
These certifications and features may be great (and yes SELinux is pretty neat stuff), but it all comes down to systems/applications implementation and workloads, and in that respect, it is possible to build very secure solutions on either platform. However, for the moment, a proper SELinux implementation (e.g. RHEL) is certified for more stringent access protection profiles, though the configuration of Windows systems submitted potentially covers more workloads (but only up to the CAP profile).
maybe you are just misinformed!
No, not misinformed – just misquoted the version. I did try to track down the specific article that I read about it – but couldn’t find it. However, the info has been correctly stated by the others responding to you.
Regardless, Linux has been certified at a higher level than Windows as a result.
Well, I think I AM giving the NSA-backed SELinux the benefit of the doubt, because I’d assume (and I think it’s reasonable to assume) the NSA know a lot about security, and that their name on a security framework means something.
Now, if what I’m reading here is correct, then it would seem to be ‘secure at all costs’… which I guess fits in with what I’d expect from the NSA, and which wouldn’t be such a good idea for a single-user home system, at least not without a massive shift in the way Linux applications are programmed.
Edited 2007-08-22 02:55
Its because so few distributions include even basic support for it out-of-the box.
Just about every distribution includes basic support for SELinux. The problem is that basic support for SELinux is useless. Any package that include a binary needs an SELinux policy, and the policy is highly distribution-specific. SELinux is a major commitment on the part of a distribution project.
SELinux isn’t something you drop into a Linux system to make it more secure. It’s a firewall that coats the boundaries between all of the internal software components of the system. Every interaction between applications, users, and resources falls under its jurisdiction. Every little piece of your system has to be SELinux-aware or your system won’t work as desired.
So you’re absolutely right. It isn’t so much that people (i.e. users and admins) are afraid. It’s distributors that are afraid. SELinux is a QA nightmare. It’s the antithesis of the “just works” experience that most Linux distributors are trying to provide. It’s dependency hell all over again, except now it’s policy hell.
Basic support? SELinux is an all-or-nothing proposition. You either dive in headfirst and provide comprehensive and sane default policies for all of your supported packages, or you decide that it’s not in the best interests of your target market. Don’t try to find a middle ground. You’re either an SELinux distribution or not.
A desktop Linux user needs a firewall, but she doesn’t need SELinux any more than she needs RAID5 with a hot spare. Even AppArmor is arguably overkill for a personal server. Leave SELinux where it belongs: in the enterprise.
Edited 2007-08-22 00:25
Butters,
You don’t need to give me a lectures on SELinux. I know what it is and how it works.
SELinux or simular is needed if being secured requires having Mandatory Access Control. Microsoft has raised the bar by including MAC via UAC, so Linux needs to embrace it as well. Posix ACLs are another area where *nix needs better coverage. ACLs provide finer tuned file and directory permissions over basic Unix style permissions.
Fedora and RHEL have a sane implementation: targeted policy with few disturbances when using the provided troubleshooting tool and configuration tool. The key is to enable Enforcing mode and at least tweaking the memory protection boolean options a bit for better coverage. Since the targetted policy only covers certain critical apps and daemons, its important to enable restrictions for broader coverage.
Edited 2007-08-22 00:45
I know you know how SELinux works, but there are others here who might not. Mostly I was challenging your assertion that other distributions, besides RHEL and Fedora, need to get behind SELinux in order to make the experience better (or something like that).
I’m glad that Red Hat has differentiated itself as the security-minded enterprise Linux distributor. It makes sense for them. And I’m pleased that they’re making better tools for creating policy.
My point is that Ubuntu (for example) adopting SELinux won’t really help shore up Red Hat’s implementation. It’s very distribution-specific. And Ubuntu isn’t the kind of distribution whose users need MAC. Many Ubuntu users have come over instead of upgrading to Vista, and for various technical and empirical reasons, they are more secure for it.
Funny you should draw the parallel to Vista UAC, since it is quite fitting. Most Windows applications aren’t designed with UAC in mind, many Vista users hate the prompts, and it is often disabled. I’m sure plenty of average Fedora users are in similar situation with SELinux. Just go away and let me do what I want.
I used to work on a team that was primarily focused on developing sophisticated kernel subsystems for dealing with bugs in other parts of the kernel. At the end of the dev cycle, I’m not sure if we made the kernel more or less reliable. Certainly more complex and a bit slower. And the common water-cooler hypothetical was, “imagine if we dedicated this much effort to finding and fixing the bugs in the first place?”
That’s how I feel about SELinux. I’m not sure whether it’s more likely that an application will malfunction because of a security breach or because of an innocent policy violation. I’d much rather we devoted all of this effort into making the system secure and reliable in the first place.
Edited 2007-08-22 01:15
Actually, SELinux is all about the reference policy. Each distribution needs to tweak the reference policy to the differences between distributions, but that is true of any security software.
Most of the work is already done for you. Ontop of that, how easy is this:
http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-bu…
With that new policy builder AND setroubleshoot{,d} it isn’t rocket surgery to set up new SELinux policies.
Even you can do it 😛
Edit added link to refpolicy:
http://oss.tresys.com/projects/refpolicy
Edited 2007-08-22 02:03
http://james-morris.livejournal.com/21473.html SELinux blocks Apache DoS
http://danwalsh.livejournal.com/10131.html SELinux prevents Samba vulnerability
http://www.linuxjournal.com/article/9176 SELinux blocks Mambo exploit
http://secunia.com/cve_reference/CVE-2006-3626/ 0day Linux kernel vulnerability that is blocked by SELinux in RHEL and Fedora.
http://archives.neohapsis.com/archives/fulldisclosure/2006-07/att-0… Previous link exploit code for you to try out on an SELinux enabled redhat box.
SELinux belongs in places where security is important.
After you’ve done a few post mortem forensic analysis’s on hacked servers, your mind might change.
Note that pretty much all of my boxes run SELinux in some form or fashion.
A desktop Linux user needs a firewall, but she doesn’t need SELinux any more than she needs RAID5 with a hot spare. Even AppArmor is arguably overkill for a personal server. Leave SELinux where it belongs: in the enterprise.
A firewall is just a tiny piece in the security chain. Imho proactive security measures could save your day. If only on one occasion. Fedora has really a lot of experience with SELinux and managed to get fc7 with an enforcing targeted policy on the road that works no different from any other distro. Fedora core 7 even includes a policy for netscape browsers (firefox and co) and mozilla thunderbird.
You’re right that SELinux can be a burden for any distro that starts implementing this advanced security mechanism. Isn’t that the case for anything complicated you begin to explore? Redhat has done the walk and it’s quite impressive how good they have managed the default policies.
Most mallware enter ones system through any web browser or an e-mail message. A firewall will not help you if malignent code sends messages hidden in udp 53 or icmp or tcp 80 fragments. Unless you disconnect the box from the network altogether.
Just a few days ago someone introduced a simplified alternative to SELinux: SMACK – Simplified Mandatory Access Kernel. Obviously there are no plans yet to merge it, but it looks like a good a approach for those looking for something easier to implement than SELinux.
http://lkml.org/lkml/2007/8/11/95
Is SELinux really necessary for general purpose security (Internet facing web/DNS/mail servers)? The two questions that would be asked in any planning or implementation meeting are (1) how hard is this tool going to be to use and (2) does the increased effort in training and maintenance justify the benefits the tool provides? Even the example provided in the article would require some testing and knowledge of what rwho is trying to do as Simon Farnsworth pointed out in his comment. In some cases that could be beyond the skill or comfort level of some administrators, in other cases they may not have the test environment necessary to fully evaluate a custom security policy before deployment.
There also isn’t a great deal of evidence showing any measurable improvement in security using SELinux over existing tried and true methods to justify the learning curve and additional complexity in order to solve current security issues. Considering I listen to PaulDotCom Security Weekly, the Security Roundtable, SECTHIS.com and other security podcasts, subscribe to SANS, scan SecurityTracker, Securiteam and SecurityFocus on a daily basis, I have yet to hear or read any article or serious discussion showing the benefits of SELinux over conventional methods of securing systems and applications. I think that SELinux can provide some benefits in certain situations, but it is definitely not a “silver bullet” to better security.
While I give props to RedHat for providing a GUI based tool to peform most of the configuration, it should also wrap the audit2allow command as well. For those who are command line shy, a full GUI would make the introduction to SELinux a lot smoother.
http://osnews.com/permalink.php?news_id=18491&comment_id=264927
While that might be true, do you have any statistics showing how Linux machines that did not have SELinux enabled fared against the same exploits?
No, but it goes without saying… As soon as h00lyshit.c hit my inbox in the full-disclosure folder I tried it out on my Ubuntu desktop. Guess what? It resulted in a root shell. Kind of creepy.
Granted, most of those were local exploits, but even still, most hacks come from the inside.
Of the five exploits you listed, three of them are local (apache, h00lys#it.c, Linux kernel race condition) and would require users with an above average understanding of both apache and the OS in oder to exploit a machine effectively. By limiting access to the systems through limited user accounts and permissions along with effective auditing of user activity would achieve the same results as using SELinux.
The Mambo exploit could have also of been prevented in the manner described by Kyle in his comment to Richard’s article. Mounting filessytems with nosuid and noexec options effectively prevents code execution as well as a complex security policy. The Samba vulnerability is easy, don’t put Windows shares where they can be accessed from the outside world without going through a VPN.
None of these vulnerabilities actually requires the capbilities of SELinux in order to protect the system, sound build practices and frequent updating can do just as much without the potential headaches of learning Mandatory Access Control.
Although this exploit is two years old, it does point out that there are potential chinks in the armor of SELinux:
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-2977
As the use of SELinux becomes more popular, so will the ways to exploit it. Using SELinux should be part of a sound security policy that includes least privilege and regular patching and upgrading cycles. No one tool is going to fix every problem.
Robert,
Good points. I wasn’t trying to say “SELinux is the be all end all security solution”. Rather I was making a point in that it does have valid security benefits. SELinux is MAC. MAC is designed to prevent misconfigurations or 0day exploits from causing any harm. In those cases, it did.
Security is a process best implemented in layers. Like a firewall, a good security policy, or only using key based authentication for ssh access, SELinux is a layer.
Again, you are totally right in that no one tool will fix every problem.
SELinux is not a silver bullet and does not protect against all types of attacks. That is where things like Exec-Shield, Fortify-Source, Smash Stack, BOD, ELFDH, and numerous other defense feature come into play. You can read about them on Fedora’s wiki.
With all things considered, you end up with a pretty comprehensive security defense team thats largely transparent, on top of timely package updates. Of course its not 100% fool-proof. The weakest layer is always between the chair and machine and no OS can completely mitigate that.
Security aside, Fedora makes a nice distro for any purpose. The GUI tools are a nice touch for migrating Windows users and things are very stable with all the updates.
I suppose it has fewer packages and an uglier theme. Thats nothing *trusted* add-on repositories and some quality time on Gnome-looks can’t fix. 🙂
Edited 2007-08-22 03:39
the easiest way is to sandbox applications.
guess what it’s the way apple chooses for leopard…
with sandboxes you just need to set a few flags like “can do this that and that”. For a very bad and innacurate comparisong, it would be a bit like targeted policy in selinux or apparmor, yet, 1000 times more simple to administrate.
Oh and of course there are solutions for this on linux which can do the simple sandboxing as well as more complicated setup (like selinux) and uses the tricks that make apparmor easier to setup(like inheritance, optionally of course).
one url comes to mind:
http://www.rsbac.org
One of the reasons why SELinux has not been so widely opted is that there is actually an easier option in the form of ApArmor (from the SUSE camp) that is much more intuitive to use and easier to setup.
I am a SLED (SUSE Linux Enterprise Desktop) user and have configured ApArmor for all of my normal desktop apps without any difficulty (it has a neat “learning” mode that does most of the hard work).
My understanding is that SELinux is more tightly controlled and hence potentially more secure but from personal experience I would say that it’s traditionally been just to difficult for “normal” users to setup and configure. (the few times I’ve tried to get SELinux working in fedora I messed it up badly enough to force me to re-install, whereas ApArmor was really intuitive and much easier to use and understand/troubleshoot).
That’s my experience anyway…
The new configuration interface GUI does look much more straight forward and I may give fedora/SELinux another go.
Regards
Darren
Hmmm… Is replying to yourself a bad thing???
I found this PDF which compares AppArmor and SELinux (it may be dated).
It does not “appear” to be excessively marketing orientated but I had a debate with myself if it were apropriate to post as a link.
http://www.novell.com/linux/security/apparmor/apparmor_overview.pdf
Disclaimer: I do not work for Novell but can and do sell Novell products, from time to time, so cannot be considered completely impartial.
Feel free to mod down if you think it’s to marketing-ish.
My understanding is that SELinux is more tightly controlled and hence potentially more secure but from personal experience I would say that it’s traditionally been just to difficult for “normal” users to setup and configure.
Well, currently AppArmor has two fairly important problems:
– It provides path-based access control, rather than access control based on a security context of a file. A user could trick AppArmor into thinking that it is ok to write to a file, while it is in reality a hardlink to another file.
– Handling of fd’s on execution of a program.
Of course, even with a completely misconfigured policy, the security of AppArmor is the same as that of a system without MAC, because traditional UNIX-like DAC is still in force. A properly written policy adds to that.
While I am convinced that SELinux is a more correct approach to MAC, in contrast to what was said by some other commenters, I believe it is too complex for many system administrators. Learning SELinux policy writing is certainly doable, but it requires a fair investment of time. I have seen enough administrators disabling SELinux, because they didn’t have the time or incentive to learn it.
AppArmor is a nice middle way, it can provide more security than UNIX DAC, and writing/modifying AppArmor policies can be learnt in a short amount of time.
In the end it is “the right tool for the job” over again. And I’d rather see sysadmins increase security by using AppArmor, than disabling SELinux (and putting nothing in place) out of frustration, or just “audit2allow -M” all denials.
@danieldk
Thank you for taking the time to reply.
I have been over the documentation for AppArmor and could not see what it’s limitations were. In a few sentances you have given me something to think about (so easily defeated by hard links etc).
I do agree with you though, AppArmour is “easy enough” that it should be used as the default, with systems with a very high risk/criticality the extra effort to get SELinux would be a good choice.
It’s all about “layers of defense” after all… The more little hurdles you can put in the way, the more secure your system in total.
Regards
Darren
Well they are design points to be aware of but I wouldn’t classify them as problems.
AppArmor uses the name as the security context. Hardlinks and bind mounts create an alias so that the file can in essence have multiple labels. This is both good and bad, it allows certain flexibility but it can also be used to circumvent policy if an application can make a hardlink to a file it shouldn’t be able to.
This is why AppArmor mediates the creation of hardlinks. A confined application can’t create a hardlink that circumvents its profile.
It is possible for hardlink mediation to be circumvented by cooperating confined tasks if bad policy is loaded or if an attacker can get an unconfined application to create the hardlink.
This actually isn’t a problem. AppArmor does fd revalidation, so that the fd is verified against a profile change, this happens for both exec and profile reloads.
Definitely, nor should sysadmins only rely on MAC which can only contain and limit a breach. Other hardening which can prevent a breach from happening is just as important.
Simply an exellent article. There was a definite need for an article like this. There existed only highly theoretical stuff until now.
I don’t mind the extra hassle of having to deal with SELinux, the only thing which does bother me are the people who create guides and various other articles on how to do things and the first thing they ask you to do is disable SELinux.
If these guide creators have the time to put the effort into writing a list of things on how to add additional things to your system, surely they could take that little bit of extra effort into learning about SELinux for additional policy files?
Even worse, here: http://www.howtoforge.com/the_perfect_desktop_fedora7_p2
The author disables gpg package integrity checking as well.