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

January 13, 2011

It has recently struck me that one of SELinux's less obvious problems
is that it is a secondary, backup security mechanism. By this I mean
that no current system depends on SELinux for its primary security
mechanism. Instead the primary security mechanism for Linux is still
Unix permissions and UIDs, and on standard distribution setups SELinux
is there purely to limit the damage if a program has a bug.

(One of the signs of this is that SELinux denials are treated as a big
deal. Imagine if your Linux system alerted you every time a program got
an EACCES when it tried to open a file.)

One of the consequences of this is that SELinux suffers from a serious
false positive problem with its alerts (for more background on this in
general, see here). Because exploits
against vulnerable programs are such a rare occurrence, almost all
SELinux alerts are in fact either bugs in your distribution's setup of
SELinux or because SELinux is fragile in the face of system changes. This both annoys people and conditions them to
assume that SELinux itself is the root cause of any problem that it
reports.

Another consequence is that time spent dealing with SELinux is almost
always wasted time. Since it is only a backup mechanism against what is
in practice a very rare event, SELinux spends most of your system's life
doing nothing useful. Time spent maintaining something that does nothing
useful is wasted time, a deadweight loss. To the extent that you don't
have to do anything to maintain SELinux, it is cheap insurance; to the
extent that you do have to do things to maintain it (and may have to
learn about an entire complicated system), it is expensive insurance
that can only be justified if you have an unusual risk profile. Turning
SELinux off if it causes you problems is, I'd argue, a completely
rational response to the situation unless you can maintain it very
cheaply.

(Remember, staff time is not free. Often it is very expensive in
practice, because it is finite and not expandable.)

As a secondary, backup system SELinux is pretty much always going to be
somewhat neglected. People involved in Linux, from sysadmins to software
authors to distribution packagers, don't have to deal with it the way
they have to deal with Unix permissions (and most of them should not
have to, not unless it becomes Linux's primary security mechanism, which
is pretty unlikely to put it one way). This neglect means that SELinux
is always likely to have problems, problems that almost never exist with
Unix permissions.

(If someone makes a mistake so that Unix permissions are wrong, it gets
noticed right away. SELinux, not so much.)

All of this compounds on itself to some degree. Distributions are trying
to push this particular rock uphill by turning on SELinux's enforcing
mode by default; if it works, this is virtuous circle where widespread
enforcing mode makes people get the SELinux configuration right, which
makes it less work to run SELinux in enforcing mode, and so on. But it
can go the other way too, where enforcing mode is too strict so people
don't use it, having warnings enabled produces too many because without
strict mode fixing the configuration isn't that important, and then
people turn SELinux off entirely.

(My personal opinion is that SELinux has one foot in each camp right
now. Distributions seem to have mostly succeeded in making SELinux work
for simple default configurations and are in the virtuous circle, but
non-default configurations go over to the other way almost immediately.)