[wplug] Who benefits from SELinux?

[Jonathan Billings]

On Apr 10, 2012, at 1:44 PM, Pat Barron wrote:
> Is there anyone reading this who can identify some particular benefit 
> the get out of using SELinux (in particular, in "Enforcing" mode)?  I 
> have to admit, when I'm installing a new system, usually the very first 
> thing I do is disable it (either in the config files, or during the 
> installation itself if the distro supports that).  I can't say I've ever 
> been in a situation where I've been glad I had SELinux enabled, usually 
> it just gets in my way - especially if I'm building stuff from source or 
> using things that are not packaged for the distro I'm using.

I deploy all our systems with SELinux enabled except for one exception, the systems running Lustre (since they still haven't got it working with SELinux, once that works we'll enable those too).  I deploy it on all our desktop systems, staff PCs and servers.  I manage it with our configuration management system.  

SELinux is a powerful tool for securing systems, and it really shouldn't be brushed aside as something for extremely secure installations or server-only.  Desktop systems greatly benefit from the security you can get from SELinux as well.  Web browsers can run in a context that has restrictions on where it can read or write.  Software can be run in sandboxes if you want to really lock it down.  You can set up confined users for less trusted logins.

I'll occasionally run into people requesting it to be turned off, but it's usually because they don't understand what's happening, they just think "turn it off so the error goes away".  Once you understand the tools, you can figure out what SELinux booleans need to be set, what file contexts might need to be fixed or custom modules need to be loaded. 

Most of the time, the problem is that someone is trying to run software in a way that isn't already described in the SELinux policy.  For example, someone trying to serve web content out of a directory in /home.  The apache httpd's domain is rather restrictive just because it is one of the more common vectors of attack.  Serving web content, particularly executables, out of home (which by its path will be labeled as home directory content and not web content) is obviously going to raise some red flags, so it is no surprise that SELinux blocks it.  But if you run the correct commands (for this example, probably something like `semanage fcontext -a -t httpd_sys_content_t "/home/webcontent(/.*)?"'), it can work.

So, really, using SELinux is just learning a new security technique.  I'm sure when you were first learning about firewalls, it was tempting to just disable it, because it just makes the errors go away.  But now it's considered a sane thing to have a proper firewall set up.  I'll admit, learning SELinux is a steep learning curve, but something that is quite powerful and useful.  Learn about the audit system, the 'semanage' command, building and installing SELinux modules, setting selinux booleans.  For Fedora/RHEL-based distros, I'd reccomend you read the Security Enhanced Linux guide (https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html).


--
Jonathan Billings <billings at negate.org>