LSS: Secure Boot

Posted Sep 13, 2012 7:38 UTC (Thu) by skitching (guest, #36856)
Parent article: LSS: Secure Boot

The article mentions "signing the bootloader". However GRUB2 isn't a monolithic application; it loads modules from the filesystem. So are all the files in /boot/grub going to be individually signed? If not, then can't I create a new module in /boot/grub, and modify grub.cfg to load it, and thereby take control of the "signed" bootloader?

And how will this affect WUBI, where the Microsoft bootloader is used to boot into Linux? That approach is specifically targeted at non-technical Windows users, ie those least likely to disable secure boot in the firmware.

What are the implications if secure boot is disabled in the firmware, then Windows is booted? Will windows refuse to run (or some programs, eg Microsoft's Genuine Windows validation checks)? If so, can a custom bootloader be used to "lie" to windows about secure-boot being enabled when it actually is not?

LSS: Secure Boot

Posted Sep 13, 2012 13:29 UTC (Thu) by pjones (subscriber, #31722) [Link] (8 responses)

In this case we're basically building grub2 as a monolithic efi binary in the package, and the module loader is disabled for additional modules. The monolithic binary is then signed.

LSS: Secure Boot

Posted Sep 13, 2012 14:44 UTC (Thu) by robertm (subscriber, #20200) [Link] (7 responses)

Hey look at that, more features gone in this rush to bend over backwards to accommodate Microsoft's anti-software-freedom initiative.

LSS: Secure Boot

Posted Sep 13, 2012 17:48 UTC (Thu) by pjones (subscriber, #31722) [Link] (3 responses)

If there's something we're not building in to that grub2 image that you actually need for something supported by our OS, then it's perfectly reasonable to file a bug to include that module so it'll be fixed. If you want more modules for something that's not supported by our OS, you have several options. They include: 1) paying VeriSign $99 to get your own access to the signing service, 2) putting your own keys in the firmware and signing your own build yourself, and 3) disabling secure boot, which will allow grub2 to load modules again. Any inconvenience is unfortunate, but any of these should be sufficient to avoid whatever problem you may have. You still have all the freedoms you had before, including the freedom to have malware install "bootkits, if you want them.

LSS: Secure Boot

Posted Sep 13, 2012 18:23 UTC (Thu) by hummassa (subscriber, #307) [Link] (2 responses)

> You still have all the freedoms you had before, including the freedom to have malware install "bootkits, if you want them.

IOW: NOTHING will, in the end, impede malware to install bootkits/jailbreaks. :-D

This way, people are doing all this work to appease Microsoft, under risk of making people think that Secure Boot (TM) is actually secure, which will after all DIMINISH the security status of potential-botnet-drones around the world. Ah, let's not forget the privacy/liberty implications. Hmm...

LSS: Secure Boot

Posted Sep 13, 2012 19:04 UTC (Thu) by pjones (subscriber, #31722) [Link] (1 responses)

Well, it's certainly not secure if you turn it off. I don't think anybody is under that illusion. But the issue you're taking here is that the status quo remains: if you do something your OS doesn't support, your OS vendor isn't going to support you. You're still free to do it, and can even do it securely - though it will require more effort from you. If you choose to disable security features instead of putting that effort in, you'll not be able to take advantage of the added security.

LSS: Secure Boot

Posted Sep 13, 2012 23:51 UTC (Thu) by hummassa (subscriber, #307) [Link]

> If you choose to disable security features instead of putting that effort in, you'll not be able to take advantage of the added security.

You know, you kind of proved my point. There is NO added security, because you can always find another vulnerability in the kernel, and use that to escalate past the bootloader (like creating crafted restore-from-hibernation images) and people will act under the illusion that their systems have "added security" when they aren't, which, as I mentioned, diminishes the overall security. For instance, the crafted restore image could allow running unsigned or signed-by-the-malware-author executables or substitute key libraries.

And again, that is my point: "Secure Boot" == "fake security", which is far worse than "no security".

And worse yet: "Secure Boot" == "you are running a signed O.S. (with Defective by Design implications and I Can Phone Home and invade your privacy implications)" OR "you are running a signed (bla bla) but COMPROMISED by malware O.S."...

LSS: Secure Boot

Posted Sep 14, 2012 12:05 UTC (Fri) by jeroen (guest, #12372) [Link] (2 responses)

The only reason GRUB 2 actually has loadable modules is that it is very difficult to load a big binary reliably with MBR booting. With UEFI that problem is gone and we can just load a monolithic GRUB. There is no reason left to keep using loadable modules with its error-prone selecting of which modules are needed at boot time to load the other modules.

LSS: Secure Boot

Posted Sep 14, 2012 14:49 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Right, I have seen the 'grub rescue>' prompt on UEFI way too many times already. (GRUB still looks up GPT partitions by index, not UUID, but repartitioning tools - or at least parted - don't seem to maintain numbering in GPTs.)

LSS: Secure Boot

Posted Sep 14, 2012 20:50 UTC (Fri) by idupree (guest, #71169) [Link]

gdisk (gptfdisk) maintains partition numbering. It's parted that likes to change it.