Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 15:18 UTC (Wed) by hummassa (guest, #307)
In reply to: Garrett: Secure Boot and Restricted Boot by xilun
Parent article: Garrett: Secure Boot and Restricted Boot

I find it funny -- strike that.
I find it HILARIOUS when people try to make a distinction between "secure" boot and "restricted boot". The infrastructure is the same, only varying the degree of control that Theoretically the end user has over the keys used to sign the bootloader and the loaded OS.

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 16:34 UTC (Wed) by raven667 (subscriber, #5198) [Link] (4 responses)

Isn't the question of who controls policy the fundamental difference between beneficial security technology (firewalls, encryption, IDS, integrity checking, etc.) and oppressive security technology (firewalls, encryption, IDS, integrity checking, etc.) ? It seems that you are arguing that all security technology is bad because it can be used for bad things, a position usually held by authoritarians (who would of course retain all the security technology for their own use), although I doubt you belong to that group.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 18:11 UTC (Wed) by hummassa (guest, #307) [Link] (3 responses)

> It seems that you are arguing that all security technology is bad because it can be used for bad things

No, that is not what I am arguing at all. I am arguing specifically (for some time now) that:

1. "secure" boot technology is not secure at all; and
2. that anything beyond "make grub* be loaded, to load whatever I want after" is a waste of time and effort AND a collaboration with microsoft's efforts to keep linux out of the next generation of PCs|tablets|whatever_gadgets coming.

* substitute for favorite|possible bootloader here

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 19:24 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

> 1. "secure" boot technology is not secure at all;

In what way is this architecture for simple integrity checking of the boot firmware and boot loader insecure against remote unauthorized attackers modifying the firmware or boot loader to hide and persist their root kits? The only attack surface I can see is the code which reads config variables which are under the possible control of an attacker, and I'm sure that code is limited and could be audited or fixed in the field to close any holes which are discovered.

Other application-security issues (buffer overflows in the browser or OS) are really not what this is about and no one is pretending that this is a miracle cure for unrelated security problems.

> 2. that anything beyond "make grub* be loaded, to load whatever I want after" is a waste of time and effort AND a collaboration with microsoft's efforts to keep linux out of the next generation of PCs|tablets|whatever_gadgets coming.

So any integrity checking of the kernel by the bootloader or of userspace by the kernel, none of which is defined by UEFI Secure Boot, is a bad thing? Is tripwire or AIDE a bad thing too? The whole point of the shim is to have total control over what boots after and to still allow you to verify that it hasn't been modified without your permission. A local user can trojan their own system if they want, I guess, Secure Boot won't attempt to stop them, but a remote attacker won't be able to do so from the running OS. At least that's the intent.

I don't see how MS is keeping Linux off the next generation of PCs when they already signed a boot loader that can boot any Linux system on a PC. As far as other gadgets, they are a mix of open and restricted devices, and no one is arguing against fighting boot-locking whenever it is encountered, MS isn't unique in this regard, most of the boot locked devices run Linux.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 21:41 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

When the kernel is insecure, when user-space is unlikely to be any better, why on earth would a rootkit *need* to modify the firmware? **ALL** it needs to do is arrange for an exploit to run early during boot. That exploit needn't even involve modifying any system binaries, if it can just exploit a bug in reading some data (which there are surely plenty - how well do,e.g., config file parsers get tested for security bugs?).

A "Secure" boot of utterly insecure software is meaningless.

Garrett: Secure Boot and Restricted Boot

Posted Apr 3, 2013 22:08 UTC (Wed) by raven667 (subscriber, #5198) [Link]

That is one opinion, but the kernel and userspace will never be any better or more secure than they are today and some people aren't willing to just throw up their hands and accept insecurity as the normal state of affairs without trying to do something about it. What you describe is correct, an exploit can be driven from config read during early boot, or attacker supplied code that exploits the system but the attack surface of config parsers is fairly small and well defined while the point where attacker supplied code can be run can be pushed later and later in the boot process via nested signature checking. Even in the case of an thoroughly compromised system the update process can be blocked but not modified so that the holes can be closed as they are found, leaving a working system which can be more reliably cleaned. Secure Boot gives you a small beachhead with which you have the opportunity to retake control of your system from a remote attacker, nothing more.