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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
