I fought for years against the culture of just turning off SELinux. I read every doc trying to Do The Right Thing when configuring the likes of vsftpd, samba or kvm.<p>Didn't manage to keep them working jerks-free long enough without disabling it. Daemons always find a way to break with selinux on with me.<p>After years, I just gave up. I feel sad about it, but just after install, I SELINUX=disabled them.<p>Is Selinux too hard? Or am I too incompetent? I really don't know.
Visibility is good, but I have found SELinux to be rather simple. Most applications can be automatically configured and supported by Ansible with SELinux enabled. Most community chef cookbooks also support SELinux to some degree (depending on how much you customize things). The default policy is "Targeted" which only protects Redhat supported applications by default. They even added the concept of unconfined users and types which makes management of the systems even easier. It's when folks try to overlay their custom apps into Redhat space that they get stuck. Overlaying your apps can be done, but you have to add the appropriate labels via semanage to the system. You can even add these custom rules in your custom rpm's.<p>If you want to see the original complexity of SELinux, use the MLS policies, remove the unconfined users and types. That is the SELinux that the NSA wrote that folks mentioned here. Dan W. at Redhat made it significantly easier. Now you can even pass the soft errors from Permissive mode into tools like audit2why or audit2allow that will suggest Boolean you can enable, or rules you might create. He also adapted it to support systemd and containers to a degree.
I do like it when security polices are compiled into the program and like it even better when they are impossible to disable. That way programs avoid getting out of sync with best security practices since they will start crashing for all users/developers. Not just users of X but not Y. However programs that try to work with pledge/capsicum/seccomp/others are great but always going to be in a very small minority. So something like SELinux and Apparmor being able to enforce policies on arbitrary software seems like a necessary seatbelt.
I used SELinux commercially in 2000 on an embedded surveillance platform project. I've never used it since, because it's such a hassle to deal with. Special snowflake systems are just so rarely the right thing to do.<p>I do believe this type of approach will become easier as CI/CD becomes the norm, but that's gonna be awhile yet.<p>IMHO to date you will often get more value for time invested out of alternate strategies like thinning down a kernel and userspace, running a server diskless with frequent reboots, adding a second server for failover, using a grsec kernel, or running a decently maintained and tuned IDS/firewall combo.