SElinux

[Benjamin Franz]

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."