[jlgaddis]

My experiences differ greatly from yours.

I've got a few dozen Linux servers of various roles (authoritative DNS, database, mail, web, etc.) publicly facing and I run SELinux on all of them from the moment they are installed (literally, it's enabled and enforced in my kickstart files).

I honestly can't recall a single issue in the last five years or so, at least, where the "fix" was "disable SELinux".

[chousuke]

My experience with Red Hat (or CentOS) is that the default SELinux policies usually work out of the box, so turning it off grants no benefit.

The few times SELinux has "broken" something the fix usually been as simple as creating an fcontext equivalence (if you want to install things in a custom path), enabling a SELinux boolean, or maybe a simple custom policy module granting some additional permissions. None of that is particularly difficult.

If you really want to lock down your custom software with SELinux or go beyond what the default Linux access controls grant you, that is definitely more work, but I've never felt that SELinux is enough of a maintenance burden that I should turn it off.

[motoboi]

I envy you. Really. I tried to be that guy who got selinux right. I couldn't.

For years I were that guy who told it's friends they are morons for turning it off.

[digi_owl]

I other words you have never deviated from the distro-provided script. In other words, the distro provider owns the server.

[jlgaddis]

Sure I have. There are some things that are done in a "non-standard" way because it works better for us.

Instead of just turning off SELinux, however, I did things "the right way" (fixing labels, contexts, etc.).