The general SELinux issue is a complex subject. My short form take is that regardless of its potential in theory if implemented nicely, in practice SELinux as deployed has consistently prioritized mathematical perfection (and yelling at people) over practical usability in the field. The real result of this has been less security than would have been achieved with a less perfect but more usable system because in the field SELinux does not degrade gracefully and so many people turn it off entirely. Some number of systems are quite secure (assuming no leaks in SELinux itself); many other systems are not secure at all. This is a bad outcome (unless you decide that only people who are dedicated enough to use SELinux really matter and everyone else is 'unprofessional' or the like), and I don't like it. I want a better outcome, one with more security that I can actually justify deploying, one where more daemons and programs are hardened to some degree even if it's not a huge amount.
(At this point the OpenBSD pledge() work is looking attractive, although there are real organizational issues that would make it hard to do in Linux.)
Perhaps one can get to a better future with SELinux by having people build and ship systems for doing little SELinux configurations for daemons or systems that read daemon configuration files so they can automatically label directories and files for your system, or any number of other user friendly ideas. But we've had something like a decade of SELinux and its usability problems at this point and it hasn't happened yet. It's hard to avoid the obvious collection of conclusions.
SELinux came from the defensive side of NSA, pre 9/11, and was not written to make Linux more secure. It was written to force application developers to re-architect their applications so they could run under a mandatory security environment. The original idea was that, once enough applications could operate under a mandatory security model, an secure OS could be put in underneath them.
NSA had had several multi-level secure operating systems developed for them in the past, but they didn't have any applications other than ones specifically written for them. SELinux was intended to remedy that.
Unfortunately, nobody seemed to understand that, and NSA doesn't do much outreach.
(At this point the OpenBSD pledge() work is looking attractive, although there are real organizational issues that would make it hard to do in Linux.)
Perhaps one can get to a better future with SELinux by having people build and ship systems for doing little SELinux configurations for daemons or systems that read daemon configuration files so they can automatically label directories and files for your system, or any number of other user friendly ideas. But we've had something like a decade of SELinux and its usability problems at this point and it hasn't happened yet. It's hard to avoid the obvious collection of conclusions.