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.)