Garrett: Secure Boot and Restricted Boot [LWN.net]

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:45 UTC (Sun) by mjg59 (subscriber, #23239)
In reply to: Garrett: Secure Boot and Restricted Boot by paulj
Parent article: Garrett: Secure Boot and Restricted Boot

And selinux would be unnecessary if userspace were already secure, so it's also pointless?

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 22:33 UTC (Sun) by hummassa (guest, #307) [Link] (6 responses)

The problem here is that our argument is: deep "secure" boot support collaborates with future restriction of boot. SElinux, OTOH, does no such thing.

You can see another difference in nomenclature: one pretends to be "secure", the other explicitly states that it is "security-enhanced". Who is blatantly lying to the consumer? :-D

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 22:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (5 responses)

So it adds security, you just worry that it can be used for evil? That's not what you said earlier.

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 13:39 UTC (Thu) by hummassa (guest, #307) [Link] (4 responses)

Actually, if you open this whole thread and search for my comments, you'll see that it's exactly what I have been saying all along.

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 14:05 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

You said

>"secure" boot does not help securing the boot process

in http://lwn.net/Articles/546340/ .

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 17:29 UTC (Thu) by hummassa (guest, #307) [Link] (1 responses)

you redacted the important part of the sentence... ;-)

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 17:36 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

The rest of it says nothing about security, so I'm not sure how it's relevant to the case in hand.

Garrett: Secure Boot and Restricted Boot

Posted Apr 11, 2013 17:43 UTC (Thu) by hummassa (guest, #307) [Link]

I will complement my last comment, above, trying to clarify my position. English is not my native language, so I apologize if not everything I think about the subject came across.

1. I believe the difference between what is called "secure" and "restricted" boot modes is a single bit in policy.

2. I do believe "secure" boot adds to security -- like locking your door, it does not add a lot, but you only has to run faster than your campmate when the bear comes. Mixing metaphors rules!

3. It is my impression that, just like locking your door, "secure" boot is not a deterrent to a determined, targeted attack... and those are the ones that worry me more.

4. In my firm opinion, "secure" boot plays into the commercial interests of the same people that are pushing, and will continue pursuing, "restricted" boot.

5. In conclusion, it is my opinion that doing any more work WRT "secure" boot once the loading shim is already signed and working is a disservice to the free and open source software community.

6. Even so, it is also my believe that I don't have the right tell you (or anyone else) what free software you should or should not work on (unless I pay you to work in whatever I want only).

7. But I have the right to think that people are being silly and pointing it out.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 5:08 UTC (Mon) by paulj (subscriber, #341) [Link]

SELinux allows the admin to control how running software interacts, including software not critical to startup, and software that interacts with the outside world, and software that dumb/malicious users might run (inc. software they load into the box). It can restrict what compromised software can do. It brings tangible benefits to securing user-space, particularly for network facing software, despite its complexity.

Security in context: What does Secure Boot add against the type of attackers sophisticated enough to subvert the kernel and modify boot? Why _aren't_ these attackers also capable of just subverting the boot, again and again?

There's a whole class of software, and methods of attacking it, that have traditionally been viewed as "not security-sensitive", which suddenly become *front-line* once you have Secure Boot, from /etc config files, to state in /var, to kernel modules, to on-disk fs data structures (h/t Al). If those fail, then there'll still be a wealth of data read by non-privileged programmes from which to get started up and then run a kernel exploit.

The Google Chrome security bounties have demonstrated that we over-estimate the benefits of just adding additional hoops, and that the X-hats are incredibly capable at stringing together exploits of long chains of bugs into attacks.