Slashdot Mirror
Red Hat Boosts SELinux With RHEL 5
E. Stride writes "Many IT managers find Security Enhanced Linux, or SELinux, to be wildly complex. The mandatory access controls originally developed by the NSA have developed a reputation for being too complicated to deal with, and many IT shops simply turn the feature off. However, Red Hat's Dan Walsh says it's the only way to ensure 100% protection in the data center."
I run fedora and on *many* message boards I see the first trouble shooting idea is to turn off SELinux. What most people forget is that you can set SELinux to be permissive, so it is still turned on, and it lets you know when applications would be doing something that would be prevented. I think changing to permissive mode SELinux is more useful than turning it off as it lets you know what applications are misbehaving. I think part of this problem is that previously there has been no easy way to look as SELinux messages and manage the policies.
The main disadvantage of AppArmor is that it relies on file paths, not the inodes. All you need to do is be able to create a hard link in the right directory to get around it.
100% agree that there is no such thing as 100% protection. I think both SELinux and AppArmor are great things (I did my MS thesis (woefully out of date) on Domain & Type enforcement which is one of the major systems (along with RBAC & Bell-Lepadula/Biba) in Mandatory Access Control (MAC). The SELinux approach is (usually) a more 'pure' variety in that it encompasses the entire system, all of the namespaces in the system in one setup. When I say 'namespace' think of that scene in the Matrix when Neo can't open his mouth to make a phone call..... Tell me Mr. HAcker, how are you going to steal my passwords when you can't even name the /etc/shadow file? SELinux will allow policies where even the root user (under certain contexts) cannot screw with the system. This can make administration harder like in some SELinux setups you literally have to login as root from the physical console to have full access, su'ing to root or SSHing in as root will not get the same privileges. In the most extreme cases, an SELinux policy could literally require you to reboot the box off of a rescue CD to get full access to certain files. The controls are extremely fine grained and very powerful, but potentially cumbersome.
AppArmor's main approach is somewhat less broad. It is more like putting certain applications into a MAC container to limit what an application can do, no matter who the user using the application is. A great example of this that most Slashdot readers should look into is putting the browser into a safety container. I've been using Linux since right before 2.4 came out, and I can't count the number of times I've heard 'Linux is more secure because even if your account gets hacked the system isn't hacked' While there is certainly truth to that from the perspective of the full system, it fails to mention that the only data I actually give a rat's ass about is the data in my account, I can always get the rest of the crap from CD/downloading! AppArmor can help fix this by saying: Hey Firefox, just because you are running as user CajunArson, you DON'T get to do everything CajunArson can do, we will only let you operate on some files, and you can't get full access to his data, you can't fork/exec any ol' program that CajunArson can, and in general you are limited to doing what you are supposed to do: Browse the Web. The underlying concepts are still based on the MAC used by SELinux, but the implementation, while not as air-tight theoretically, is also easier to adjust. If there is something I really need firefox to do that the profile will not allow, AppArmor makes the process of tweaking the security easier than SELinux in general (although RedHat could be working on better SELinux tools to fix that).
Sorry for the long post, but remember: the next time someone says Linux is more secure than Windows, remember that things like SELinux and AppArmor really are what make it better, not just because it has a mean looking penguin!
AntiFA: An abbreviation for Anti First Amendment.
For those who may not fully understand what SELinux actually does, let me give you an example.
With SELinux enabled, by detault Apache will be prevented from accessing files other than those of very basic web apps, it cannot open sockets to other hosts, etc.
For IntErnet applications this is quite reasonable and with the machine on the most hostile network around you really should use SELinux. It won't stop a break in but it can seriously curtail the effects of one.
For an IntrAnet application that is trying to write to custom log files and talk to LDAP servers and such, SELinux is not going to let you do that. At this point you have two choices - 1) tweek SELinux properties to allow only the specific functionality required by the application or 2) disable SELinux for that entire application. Considering an IntrAnet affords some physical protection, SELinux is less important in that environment and therefore, in this scenario, if you're really not savvy with SELinux and you don't have the time to get into it, I recommend just disabling it for entire application using it.
For example, to disable SELinux just for Apache you do:
# setsebool -P httpd_disable_trans 1
# service httpd restart
Note that SELinux uses db files that remember these changes so they will persist across reboots and there are no config files to edit. It's a nice system because it's easy to add these commands to install scripts and such.
So don't get bent about SELinux. Learn enough to disable it for specific apps and then turn it on all over. Keep an eye on the log files. If SELinux is stopping access to things by apps it will report it in the log file. Then determine if the app should be doing that and if so disable SELinux just for that app.
Whatever Redhat says, the fact remains that SELinux is an incredibly complex, and incredibly undocumented (or under-documented) piece of software. It took me two months to really understand how it worked and what exactly to configure when I needed to fine-tune access rights and permissions on our servers. That is a nightmare I wouldn't wish on anyone.
Redhat is not going to get much traction from this unless there is a very easy to use tool (preferably with GUI) to configure and customize SELinux, out of the box. The default tools on RHEL allow a few options during install time, but it is truly primitive.
There really doesn't need to be this huge love/hate relationship with SELinux, in fact why not just throw it out and use something far simpler and neater? There are several options out there. Off the top of my head I can think of GRSEC : http://www.grsecurity.net/
We've been using this on two of our server farms and it's been doing a superb job, and it is very very easy to customize compared to the SElinux nightmare.
Permissive mode is only useful for policy development. The kernel does not enforce the security policy in permissive mode so it is no more secure than turning it off.
Enforcing mode = Security policy decisions are enforced, policy violations are logged.
Permissive mode = Security policy decisions are not enforced, policy violations are logged.
Disabled = Security policy decisions are not computed.