SELinux & Return On Time Invested

by Bob Plankers on May 7, 2013 · 8 comments

in Cloud,Security,System Administration,Virtualization

I’m a little behind on my reading, but I wanted to address Major Hayden’s blog posts about disabling Security-Enhanced Linux, or SELinux, which brings mandatory access control to Linux. Mandatory access control is a completely different permission model for UNIX-based hosts, and Mr. Hayden feels it is underutilized:

After many discussions with fellow Linux users, I’ve come to realize that most seem to disable SELinux rather than understand why it’s denying access. In an effort to turn the tide, I’ve created a new site as a public service to SELinux cowards everywhere:

It’s pretty rare for me to argue against a security technology but in my eyes SELinux isn’t a solution to very many problems. I know how SELinux works, what it does, how to configure it and troubleshoot it, and as a result I disable it everywhere. Here’s why:

1. While SELinux ships as part of most Linux distributions, few distribution maintainers have it set up correctly for all the services that ship with their OS. Perhaps web servers work fine if you use the defaults, but deviate from those, or install another service like a mail server or tftpd and there’s a real good chance it’ll malfunction. And by “malfunction” I mean “fail silently” which just leads to a bunch of time spent troubleshooting. That’s time out of my life I’m never getting back again. On top of that, patching those distributions sometimes resets the SELinux configurations, which both annoying and a symptom of Linux vendors not caring enough to do a good job. You can deal with patching problems with more testing, but that’s also more time and effort down the drain.


2. Absolutely no third-party vendors support SELinux[0]. Which is unfortunate, as that’s one of the most compelling use cases since those vendors often have gaping, unpatched security holes in their products. As a result it’s rare that you’ll have an entire environment with SELinux turned on, which means you’ve just added yet another variable to account for in your data center (has SELinux enabled, has SELinux in permissive mode, or does not have SELinux enabled), three times as many system configurations to account for, and you should do three times more testing, too.

3. SELinux protects the interface between applications and the OS. It doesn’t inherently protect the application, beyond keeping the host itself secure. That’s important, but less so now that we have clouds and virtualization. Back when we bought one expensive server, ran one OS image on that server, and ran a ton of different apps alongside each other in that single OS image it was very important to protect one application from another. Now that we have lots of smaller OS images running in isolation inside virtual machine monitors the focus is on application security. If an intruder breaks through the application and manages to do something to the OS you redeploy the application on a fresh VM. Only this time it’s with the latest OS & application patches applied, too.

For busy IT shops and busy sysadmins return on investment is always a factor. In my eyes SELinux is a tool which will never save you enough time to justify having implemented it in the first place. Very low ROI. When it is up to me I’d rather see scarce IT time and money spent on more productive security initiatives:

  • Implementing regular OS patching. So few places do this well or in a timely fashion and it treats the root cause of many security problems directly. SELinux treats symptoms, not causes.
  • Implementing better service design, so that patching and system outages can take place without service outages, and that services might be scalable to handle additional workload from users or denial-of-service attacks.
  • Implementing configuration management tools, like Chef or Puppet. If time is money these systems print money. They open the door to better testing, rapid & repeatable deployments, elastic performance scaling, and good system documentation. I’ve also found they also lead to better, tighter security controls. For example, instead of adding large IP ranges to firewall rules “because it’s easier” you add just the specific IPs you need. With these tools it’s not a big deal to add another IP later if you need to. It’s also possible to do configuration audits with these tools, thereby finding discrepancies, potential backdoors, permission errors, etc. Heck, proper implementation of these tools should make enabling SELinux easier, but I still would take a critical look at the overall ROI of that decision versus other moves you can make.
  • Implementing better application security, whether it’s code reviews, automated code testing, IDS/IPS, patching third-party apps, etc. The application is where your data lives and is often the weakest link in the security chain. Nowadays the OS is expendable, and rather than protect the OS under the application we should focus instead on hardening the application itself. You focus on intruders coming into your house via the doors and windows, right? Not through the middle of the basement floor.

In an ideal world we’d all have time to set this sort of thing up, and it would work perfectly. This isn’t an ideal world, and as such compromises are made. Don’t let someone shame you into wasting your time by calling you a SELinux coward. You’re in good company[1].


[0] I have not checked all of them. It’s possible one or two do, but I would be surprised.

[1] At the very least you have company. :)


Comments on this entry are closed.

Previous post:

Next post: