Drawing lessons from fatal SELinux bug #1054350

[Kevin Kofler]

drago01 wrote:
> The "feature" is called security. By your logic everyone should be
> root,

For home user machines, that wouldn't necessarily be a bad thing (but it 
would mean fixing the software that special-cases the root user improperly 
for no good reason).

Alternatively, the kernel could be patched to give "admin users" (either 
defined as members of the "wheel" group as now, or by some additional 
property that would be set for the same users by default) some strategic 
capabilities such as dac_override. That would also put an end to the endless 
annoyance of having to sudo all the time. (And by the way, sudo and 
PolicyKit actions should be allowed with no password (rather than the user 
password as now) for wheel group members by default.) That way, you still 
get the benefits from different accounts, e.g., different preferences per 
family member, without the current restrictions imposed to "normal" users.

The endless password prompts make a lot of sense in controlled corporate 
environments with dedicated system administrators, but on home machines, 
they are just an unnecessary annoyance.

>> * SELinux works by shipping a "policy" that effectively tries to specify
>> in one single place (read: single point of failure!) everything any
>> program in Fedora (scalability disaster!) ever wants to do
>> (second-guessing its actual code, i.e., duplication of all logic!).
> 
> That's not how it works not how it supposed to work. Please read on MAC.

Uh, I know how it works. The above is how I summarize it. If you think that 
is incorrect, please explain HOW.

>> * An update to that SELinux policy was shipped that BREAKS the most
>> critical tools in Fedora, the ones required to update the system and thus
>> install the fixes for any regressions, including the very regression that
>> caused the breakage. And also any automated workarounds are blocked by
>> design.
> 
> No idea what "automated workaround" means but there are other ways to
> deal with it see Colin's post.

A %pretrans scriptlet that fixes the problem without manual user 
intervention (other than OKing the update). But SELinux won't allow RPMs to 
mess with it that way (especially without invoking an external executable, 
which is blocked by the faulty policy) because it would defeat its flawed 
security model.

> Yeah so we should find out why this happened and improve the testing
> procedures to not let it happen in the feature (again see Colin's mail).

NO amount of testing is going to prevent regressions from happening 
occasionally. This means:
* we need to eliminate common sources of regressions such as SELinux, to 
prevent whole classes of regressions from occurring in the first place 
(prevention is better than duct tape!) and
* we have to accept that regressions can always happen and allow for fast 
fixes to those regressions (direct stable pushes).

>> So, what needs to happen:
>> * SELinux must be disabled (or preferably, not installed in the first
>> place, to avoid wasting space for nothing) by default! Just consider the
>> benefits (none!)
> 
> As stated above that's not true.

As stated above, that IS true. :-)

>> * The Update Policies must be repealed. This regression has shown us that
>> not only they totally failed at preventing it, but they are actively
>> contributing to exposing MORE users to broken updates by delaying
>> regression fixes. (This kind of regression fixes needs to go out DIRECTLY
>> to stable!)
> 
> This is a contradiction "our current testing didn't find the bug so
> how about we do no testing at all".

There is no contradiction. Doing away with policies that do not work is 
perfectly logical, as is allowing quick regression fixes because regressions 
do happen no matter how much you test.

        Kevin Kofler