On Sat, 1 Apr 2006, Craig White wrote:
SELinux stuff isn't hard. But it does take a few minutes of time and attention to deal with the 'blocks' that arise - but it is these 'blocks' that confirm why it's installed in the first place. Granted it's easier to shut it off and I'm sure that when you are groping for justification for shutting off a layer of security on your Linux box, your above makes sense. The layer of security is for your benefit. Heck - why not shut off iptables? ' /sbin/service iptables stop' that makes it easier to use too. The reason you don't turn off iptables is because common sense tells you that it's a mistake. The same common sense should apply to SELinux - regardless of whether Debian/SuSE/Ubuntu etc. includes it.
I decline to have SELinux occasionally grab the steering wheel and try to take my machine over a cliff so I can act as Redhat's Beta Tester for their selinux-policies. It is, and will remain, turned disabled on my production servers until I am comfortable that more learning curve incidents by Redhat where an update causes previously working machines to suddenly have problems are not going to happen.
Redhat did significant damage to my trust level regarding their ability to safely deploy things that significantly extend the security model of linux with their handling of both auditd and SELinux. Too often lately, Redhat's efforts on the security front have 'made my machine more unstable' rather than 'made it more secure'.
In a year or two, when show stopping bugs in SELinux policies that were being updated _literally_ every other week are only distant memories, I'll consider turning it on in any higher mode than 'permissive'.
Until then, the conservative position, the one focused on minimizing the threats to my system's stable operation from _whatever_ source (INCLUDING system updates from Redhat) says 'SELinux stays disabled'.
-- Benjamin Franz "Once burned, twice shy."
