4 ms·
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 an
by jlgaddis 10y ago
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 10y agoMy 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 10y agoI 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 10y agoI other words you have never deviated from the distro-provided script. In other words, the distro provider owns the server.
- jlgaddis 10y agoSure 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.).