== My problem with SELinux

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 SELinuxGotcha]], 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.)