Drawing lessons from fatal SELinux bug #1054350

Kevin Kofler kevin.kofler at chello.at
Sat Jan 25 20:51:54 UTC 2014

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.

> 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:

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)…

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

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

> 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 

        Kevin Kofler

More information about the devel mailing list