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