Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 16:51 UTC (Sun) by paulj (subscriber, #341)
In reply to: Garrett: Secure Boot and Restricted Boot by raven667
Parent article: Garrett: Secure Boot and Restricted Boot

It doesn't matter, if you simply can't buy a platform that doesn't have integrity checking. Further, the lack of a flag in Secure Boot does not preclude that flag being added. If/when it is added, it will not affect software that doesn't know about it.

The hard part to getting Restricted Boot deployed was always going to be the non-MS OSes and allowing them to still boot. The major non-MS PC OS has happily gone along with implementing the required interface. The lack of a flag today, or addition of any future one, will now not prevent those OSes booting in Restricted Boot mode, should the bit ever get flipped.

If that happens, the Linux vendors will no longer have any meaningful dog in the fight, with which to raise a stink about.

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 17:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (31 responses)

"the lack of a flag in Secure Boot does not preclude that flag being added"

Correct - it's the fact that it's impossible to add such a flag that precludes that flag being added.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:10 UTC (Sun) by paulj (subscriber, #341) [Link] (30 responses)

Why would it be impossible?

I think it'd be impossible for it to be impossible tbh.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:15 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (29 responses)

If you can trust the firmware, there's no point in the firmware setting a flag to indicate that it's trusted. If you can't trust the firmware, you can't trust the state of any flag it's providing.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:46 UTC (Sun) by hummassa (guest, #307) [Link] (19 responses)

Garrett, you keep ignoring the point here; and that is: "secure" boot does not help securing the boot process, but it DOES help the bad guys to push restricted boot down the line.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 18:56 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (18 responses)

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

By that argument selinux doesn't improve security because there exist kernel exploits that allow you to disable it. Having a separate root account doesn't improve security because there exist userspace exploits that allow elevation of privileges. Passwords don't improve security because there are flaws in web browsers that allow attackers to run keyloggers.

Security isn't binary. Secure Boot on its own doesn't make the boot process entirely secure, but it does make it more secure. It's also a prerequisite for any real security implementation.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:35 UTC (Sun) by paulj (subscriber, #341) [Link] (17 responses)

raven667 also gave the "security isn't binary" argument before, my response to that is at: http://lwn.net/Articles/545877/

The problem with your example is that you have the pre-requisites the wrong way around. A more secure/controlled user-space, which technologies like SELinux try to give, is the *pre-requisite for Secure Boot*. Further, Secure Boot *also* requires a secure kernel, at least one a lot more secure than we have today. We are a *long* way from having this.

Now, once you have secured kernel and user-space to the point you can have some confidence that all software that is guaranteed to run (e.g. start-up) is unlikely to be subverted by the class of attacker you're worried about, then here's the funny thing: You don't need Secure Boot anymore!

The amazing thing about Secure Boot is that for it to worth anything to the owner, it requires the very thing that would render it moot.

However, Secure Boot is still worth something to others - it gets "Restricted Boot \ 1 flag" implemented, deployed and supported by Windows and all the major PC OSes. When that is done, then if someone flips that bit, there will be no Linux vendor left who can say "that breaks our boot".

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:45 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (8 responses)

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

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.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 21:51 UTC (Sun) by kleptog (subscriber, #1183) [Link] (7 responses)

Secure Boot doesn't require a secure kernel. Let's assume the kernel is insecure, a reasonably valid assumption as you point out.

Case 1: Malware uses a vulnerability in the kernel to join a botnet and hide itself from userspace. This is out of scope for secure boot so not relevant.

Case 2: Malware uses a vulnerability in the kernel to modify the boot sector so it gets run the next time the computer starts up. The next boot the firmware checks the boot sector and complains to the user that there's an unverified boot sector and that the user should use a boot CD to clean it. Secure Boot achieves it's goal because it's impossible for the malware to install a boot sector that passes the test.

Now you can say that the malware will just install itself into /etc/rc.d/ instead and you'd be right. That's just because no-one has written the code to do any verification on that directory, not because it's not possible. Those tests would be effective at preventing the malware running on boot *even if the kernel was insecure*.

The only thing Microsoft (really Verisign) requires before signing a bootloader is that it can't be used by malware to subvert the windows boot process so it can pass the boot sector test. But this is a social problem which can't be solved by technical means. That's why a bootloader which says "Hi! You're booting MyBootLoader. If this is not what you're expecting contact technical support. Press any key to continue." would probably get signed since it won't allow malware to hide itself.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 22:44 UTC (Sun) by viro (subscriber, #7872) [Link] (6 responses)

Bullshit. Suppose the kernel hole in question is in e.g. parsing on-disk metadata. You are going to mount root fs, right? And all the "let's make sure /etc/rc.d/ isn't modified" crap in the world is not going to do anything about that, since no visible files need to be modified.

And before you go into "oh, but that reduces attack surface" - not really. Consider a combination of (1) hole in some piece of shit desktop software that goes through luser's homedir and cross-references his pr0n stash^W^Wphoto collection with (2) kernel exploit of any kind used by the code hidden in said collection and executed by (1). Sure, it'll wait until the luser logs in. BFD.

Once a box had been had, it's been had, period.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 2:10 UTC (Mon) by raven667 (subscriber, #5198) [Link]

That sounds like a nasty scenario but I don't think any general security technology can fix that but even in this case you could safely download an updated kernel and the most your fully owned system could do is block the update, it couldn't modify it.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 18:09 UTC (Mon) by kleptog (subscriber, #1183) [Link] (4 responses)

Sure, it'll wait until the luser logs in. BFD.

Actually, I find this a BFD. It means the virus scanner started at boot has a chance to download new signatures and scan for the malware before it has a chance to run. That's a significant improvement over the current situation.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 20:26 UTC (Mon) by viro (subscriber, #7872) [Link] (3 responses)

In which respect? That Scamantec and their ilk get money from more suckers? I had a front-seat view of some of their games and I'd trust a politician sooner than those shits. If you rely on their products, you deserve everything you get - stupidity must be punished, after all...

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 22:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So when is Linux going to be completely exploit-free with rigidly defined security sandboxes isolating applications' data?

What? You say "never"?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 11:32 UTC (Tue) by hummassa (guest, #307) [Link] (1 responses)

I seriously doubt this goal is even possible.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 15:27 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

And that's why antiviruses are a practical compromise. Yes, they are an ugly kludge but reality is also quite ugly.

If Linux were as popular as Windows then it would have needed antivirus-like applications as well.

And yes, Android actually already has an antivirus app that runs on Google's servers.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:36 UTC (Sun) by paulj (subscriber, #341) [Link] (8 responses)

Then this flag argument is generally specious, and there is no Restricted Boot that needs it.

Garrett: Secure Boot and Restricted Boot

Posted Apr 7, 2013 20:50 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (7 responses)

Right. So Secure Boot is completely worthless as a DRM-enforcement mechanism. Restricted Boot is not.

Garrett: Secure Boot and Restricted Boot

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

Restricted Boot doesn't need a flag either. There are systems which big media companies assume to be secure and have working DRM, simply by dint of platform information. No other flags needed. It might not be true, but it seems to be good enough for the likes of the BBC.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 6:32 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (5 responses)

I have no idea what you're trying to say here, so I'm just going to reiterate that there's no way to use Secure Boot as a DRM mechanism and if you disagree then you can describe exactly how it's supposed to work.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 6:41 UTC (Mon) by paulj (subscriber, #341) [Link] (4 responses)

You recognise Restricted Boot is useful for building a DRM system (2 comments above this). You say a flag is pointless for Secure Boot, it is then equally pointless for Restricted Boot, by the very same argument. I don't even know why this flag issue was brought up (I didn't).

The fact still remains that "Secure Boot" differs from "Restricted Boot" by 1 bit of information, which is at the whim of a number of hardware vendors.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 6:55 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

So… you're agreeing that Secure Boot isn't useful as a DRM mechanism? Like I said, I have no idea what you're trying to say here.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 7:23 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

You have said Restricted Boot is useful for a DRM system. You don't seem to quibble that Secure Boot and Restricted Boot differ by anything more significant than a bit of information controlled by the maker. I'm sure you're more than intelligent to understand what the implication is, should you be motivated to understand.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 14:34 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

No, I think you're going to have to be explicit about what you're saying.

Garrett: Secure Boot and Restricted Boot

Posted Apr 8, 2013 18:21 UTC (Mon) by kleptog (subscriber, #1183) [Link]

Actually, I'd like clarification how Restricted Boot helps a DRM system. AFAICS it will merely lull media companies into a false sense of security because they might think it actually secures the system while it only secures the boot process.

Take any software that implements DRM, run it in a VM and you can bypass anything. You will need to arrange to run the exploit every boot though.

I find most interesting the contrast:

Securing a PC against malware - good
Securing an platform against hacks on the DRM - bad

While these two situations are technically indistinguishable.