Drawing lessons from fatal SELinux bug #1054350

[Dominick Grift]

On Sat, 2014-01-25 at 21:51 +0100, Kevin Kofler wrote:
> Dominick Grift wrote:
> > No, that is a different discussion.
> 
> Nonsense. That SELinux should be disabled is the whole point of this thread 
> (I know, I have started it!), all the suggestions (in the various 
> subthreads) of how to paper over the problem are off topic.
> 

Sorry, I must have misinterpreted the subject: "Drawing lessons from
fatal SELinux bug"

> > Disabling SELinux does nothing to solve this.
> 
> Oh sure it does. It eliminates this whole class of breakage (critical 
> components unable to do their job because SELinux gets in their way) once 
> and for all. This type of breakage keeps occurring, in fact one instance is 
> still ongoing in Rawhide while we're discussing this:
> https://bugzilla.redhat.com/show_bug.cgi?id=1052317
> 
> Disable SELinux and nothing will keep those components (RPM, display 
> managers, etc.) from doing their work.
>
> > If anything, to me this is confirmation of why we need a good SELinux
> > implementation. If this would happen to any other component then a good
> > SELinux implementation could have contained the damage caused by issues
> > just like this one.
> 
> You don't seem to understand at all what SELinux is (it is not a tool 
> magically able to fix bugs, its only purpose is to keep programs from doing 
> their work)…

I did not mean to suggest that. I meant to suggest that SELinux would be
able to contain the damage, referring to "fatal" in: "Drawing lessons
from fatal SELinux bug"

> > The SELinux experience can, in my view be improved, and i believe your
> > problem is not with SELinux itself but with how it is
> > configured/implemented by default.
> 
> … nor what it can or cannot do. (No amount of configuration can make SELinux 
> do anything other than block (i.e. break) things.)
> 

Actually it is the other way around. SELinux blocks everything by
default. Everything needs to be explicitly allowed by means of
"configuration"

> > I just believe that a little team coordination, and a little more care
> > can go a long way, and that that is likely more efficient than trying to
> > create tests that would catch all of the bugs which sounds like utopia
> > to me.
> 
> What "coordination"?

For example coordinate who does what where and when.

> 
> > I am not saying that the tests can't be improved or that they should not
> > be improved. It's just that in this case a little bit more care and a
> > double check by another involved party would probably have prevent this,
> > and similar other issues, in my view.
> 
> Sure, dropping autokarma could help (and should be done in any case, that 
> Bodhi "feature" never made any sense), but ultimately there's no way around 
> disabling SELinux. Enabling it by default in Fedora has always been a 
> mistake!
> 
>         Kevin Kofler
>