Drawing lessons from fatal SELinux bug #1054350
dominick.grift at gmail.com
Sat Jan 25 21:08:29 UTC 2014
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:
> 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
> > 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
> Kevin Kofler
More information about the devel