Quoting Peter Ross (petrosssit@gmail.com): [SELinux 'targeted' policy:]
In reality, I have seen a lot of servers which disable the enforced policy.
I worked at a very large EDA-industry company in the 2000s that, per corporate mandate, disabled SELinux on _all_ of its RHEL deployments. As a member of the Linux Management department, this pretty much made me dispair of the firm surviving, let alone developing clue.
It is a good reason why Theo de Raadt dismissed it recently in a slide show (sorry, cannot find it at the moment.)
Can't find that either, but he had a recent (June) post to his 'tech' mailing list talking about the complexity introduced by programs written in the Berkeley packet filter (BPF) language being 'insane', those being dictated by SELinux's invocation of the seccomp() syscall to do all but the simplest sandboxing. Reference here: https://lwn.net/Articles/651700/
BTW: I am aware that I am not restricting myself to the Linux kernel only.
As is appropriate! BTW, I assume many have read the news about grsecurity going restricted for somewhat understandable reasons. https://grsecurity.net/ Important Notice Regarding Public Availability of Stable Patches Due to continued violations by several companies in the embedded industry of grsecurity's trademark and registered copyrights, effective September 9th 2015 stable patches of grsecurity are being made available to sponsors and commercial support customers only. For more information, read the full announcement. [link] Dismaying. I am curious what the commentariat considers best practices hardening for Linux kernel + userspace in the wake of this announcement. PaX, AppArmor...? -- Cheers, (morganj): 0 is false and 1 is true, correct? Rick Moen (alec_eso): 1, morganj rick@linuxmafia.com (morganj): bastard. McQ! (4x80) -- seen on IRC