Drawing lessons from fatal SELinux bug #1054350

[Kevin Kofler]

Dominick Grift wrote:
> 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"

And by what magic would it do that? SELinux cannot by its nature contain any 
damage of the "the system is broken" type, no matter in what component. The 
ONLY type of damage it can possibly contain is a security hole (and even 
there, not all classes of security holes). All those fatal regressions where 
basic system functionality such as upgrading or even logging in is non-
functional can absolutely NOT be fixed by SELinux.

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

Yes. This "default deny" attitude is a big part of the problem. (Whenever a 
program covered by a strict policy gets a new feature, the SELinux policy 
has to be updated to allow it, i.e. a duplication of efforts and a 
maintainability nightmare.) But no matter what you configure SELinux to 
allow, it will only work if the program is coded to do it in the first 
place, so you cannot use SELinux to fix a regression in another critical 
component. The only regressions you can possibly fix with an SELinux update 
are regressions in SELinux itself, i.e., the ones that can trivially be 
avoided by disabling SELinux in the first place.

So I still don't follow when you claim SELinux can fix regressions 
elsewhere. That argument just doesn't make sense, sorry.

        Kevin Kofler