Drawing lessons from fatal SELinux bug #1054350

Dominick Grift dominick.grift at gmail.com
Sat Jan 25 19:00:54 UTC 2014

On Sat, 2014-01-25 at 19:10 +0100, Kevin Kofler wrote:

> > Never the less, I think this issue could have been prevented even before
> > a package was spun.
> Yes, by disabling SELinux by default. :-)

No, that is a different discussion. Disabling SELinux does nothing to
solve this. 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.

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.

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.

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.

More information about the devel mailing list