Chris's Wiki :: blog/linux/SELinuxMyProblem

My problem with SELinux

January 11, 2011

I think that my core problem with SELinux is that it is very fragile. By this I don't mean that it's buggy and so breaks in normal operation (because as far as I can tell it generally doesn't), but instead that a SELinux configured system is not resilient to changes. If you run the system exactly as your distribution delivered it, with everything in the same places and with the same user-ids and so on, the result generally works.

(You start running into potential problems if you run less common software, because all of its configuration is less well tested.)

However, when you start changing your system all bets are off. Do you want Apache's data to be somewhere other than the system standard? Do you want MySQL to store databases somewhere besides /var, because you have a really big /db filesystem? You generally lose. Unless you know enough to carefully modify your SELinux configuration (and keep the modifications intact when you do things), SELinux will break things; it will stop daemons from starting, it will prevent programs from reading files, and so on. Many of these failures are mysterious ones, where operations that should work fail inexplicably. Often they work if you run them by hand, which vastly complicates troubleshooting.

This is why I say that SELinux is fragile and it makes your system fragile. If you change things, you run a high risk of breaking something. If you are not familiar with SELinux and how your distribution uses it, it is hard to find what is broken and fix it again; it's generally simpler to turn off SELinux entirely.

Part of the problem is that SELinux labeling for files is often partially redundant information; for example, you specify the MySQL database directory in a configuration file, and then you 'specify' it again by putting the right SELinux label on it. SELinux would be significantly easier to work with and less fragile if you did not have this redundancy, so that some part of the SELinux system read your MySQL configuration and automatically set the labels appropriately.

(Then you could change your configuration once, in the way that you expect to, instead of twice. As a sysadmin I don't like redundancy in configuration settings because it's an opportunity for errors and inconsistencies to creep in.)

Comments on this page:

From 97.112.3.56 at 2011-01-12 08:24:31:

By that reasoning though aren't the user:group permissions settings also redundant information. If you start moving stuff around you already are setting file system permissions since you db directory has to be writable by your database server etc. SELinux seems to be a difference in degree not a difference in kind to what you already have to do if you start moving things from your distro's default location. We turn it off where I work as well since we have never bothered to really learn how to use it, but I am not sure how much more fragile it is than regular file system permissions.

By cks at 2011-01-12 12:09:05:

My short answer is that SELinux permissions are different from regular file permissions in that SELinux stuff is both redundant (mostly) with regular file permissions and invisible. When your database directory is not owned by the right user you get straightforward error messages and you can immediately see the problem with ls -ld; when SELinux permissions are wrong, you get error messages that don't point to SELinux as the culprit and you have to remember the special ways to see SELinux information.

I think that SELinux would be a fair bit easier to work with if there was an errno value for 'SELinux access denied', so that you could at least immediately see what the problem was. (I've written about this at more length in ExplicitExtraSecurity.)

From 65.172.155.230 at 2011-01-12 13:05:34:

I don't think "fragile" is the right word, although I understand why you chose it. I've been bitten by ssh doing aggressive checks on user:group/mode and probably said it was fragile ... but I think a better word is opaque. When something goes wrong, all you see is "permission denied" on some random operation and are left guessing wtf that means.

If ssh said somewhere, failing to auth. because I don't like the fact user "foo" allows group "bar" access to /home/foo ... then it would be sane.

Dito. if something obvious said "MySQL can't run atm. because it's db is on /db which is an NFS mount, and thus. doesn't have the selinux label mysql_db_t (or whatever)."

setroubleshoot tries to do the later thing, but it's fair to say it's still not 100% effective (esp. on a server where you need to actively run sedispatch).

By cks at 2011-01-13 14:05:45:

I would call SELinux both fragile and opaque. Even if SELinux issues gave you clear error messages, it would still be the case that changing your system around would give you a cascade of SELinux errors.

(If SELinux was less opaque and more visible maybe this would come to be seen as a routine part of moving things around, just like chown'ing your database directory to the PostgreSQL user is today. But I'm not convinced of that.)

From 194.74.151.201 at 2011-01-14 07:06:08:

The biggest problem with SELinux isn't SELinux itself. It's the human brain. It is about rewriting the years of diagnosis process that you have accumulated to date and inserting a new task in at the top of the stack, called "check SEL". A simple glance in the audit logs with do. As soon as you're able to remember that early in your diagnosis process then any frustration that it might cause is greatly reduced.

Targetted Policies vastly simplify the process of working with SEL. A lot of effort has been made to ensure that things work out of the box with sensible defaults. If one of your particular pain points is the restructuring of the filesystem layout, then may it's an indication that you shouldn't be doing that? Adding additional fcontext patterns isn't difficult. But it's difficulty pales in comparison to the technical debt that you can slowly accumulate by straying from FHS and implementing your own conventions.

-Dan Carley

Written on 11 January 2011.

«	The optimistic view of SELinux's real purpose

One of SELinux's problems is that it's a backup mechanism