Weekly Edition
Return to the Distributions page
| |||||||||||||
Garrett: UEFI Secure boot in Fedora: status update
Matthew Garrett has a progress report on
implementing secure boot in Fedora. "The infrastructure for signing the bootloader binaries is now implemented. pesign is in the archive and being used to sign shim, grub2 and the kernel. At the moment they're all being signed by test keys, and the private key is actually in the pesign package. This is, obviously, not intended for production use - it's just to ensure that we can build correctly signed images. We've proof-of-concepted signing via cryptographic hardware and will shortly be deploying new build systems dedicated to building the signed binaries. These won't be general access systems and will have a lightly modified mock configuration to ensure that the crypto hardware is available to the build chroots, but otherwise there's nothing special about them."
(Log in to post comments)
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 4:18 UTC (Thu) by theophrastus (guest, #80847) [Link]
I still wish one of you kindly experts would concoct a block diagram ("comic-book") description of the functional blocks involved in the exchange of information/keys that is expected to normally happen during a "UEFI Secure Boot" process.
Even "Alice and Bob" (http://en.wikipedia.org/wiki/Alice_and_Bob) would be sufficient. For instance, it's the case that under this system all kernel compiles have to be signed by a "Peggy", "Victor", "Trent" or "Walter"? in this case Red Hat Inc?
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 8:15 UTC (Thu) by ledow (guest, #11753) [Link]
I believe it's something like:
Shim (signed by a key known to the PC's BIOS)
The idea being that the shim is the only thing needing "approval" by an outside process (UEFI) and never changes, and the bootloader can be one of multiple bootloaders (GRUB, LILO or whatever can support UEFI), and the bootloader can (optionally, I believe) verify the integrity of the kernel and decide whether to continue booting or not.
So users of the original distro to sign code will be able to replace the kernel with whatever they want (in theory) so long as they configure the bootloader to approve it. They can also choose any of the "approved" bootloaders.
Users of other distros can "borrow" the shim and (depending on how it's designed) boot their own bootloaders, or boot the verified bootloaders from the original distro which can then boot any kernel (maybe even signed, I think, but just not signed by the original distro).
It's all a bit of a mess, to be honest, and doesn't really stop any of the problems experienced in daily life (just how often is your kernel compromised on BOOT compared to anything else? And why did you not just enable BIOS boot-sector protection with a verified-clean bootloader that could do kernel verification for you?) while providing perfect incentive to lock devices down to supplied-kernels that can never, ever be changed (smartphones, set-top boxes, etc.).
Notice that the only part that needs outside approval is the shim loader (and how they go about verifying that no-one can use that shim to boot other things or subvert another operating system by booting into malware is an interesting question about their whole approval process) which is also the only key that needs to be in the PC BIOS (and that's contentious in itself because surely it's up to the manufacturer what keys they use and also how do you update old machines with new keys? And if you can just add-a-key to the BIOS - which is the standard line about "retaining control" on your PC - why do we need the approval process at all when we could all just enter the relevant key into the BIOS for the OS we want to use?)
Everywhere else is signed by something known to the shim (which *SHOULD* allow you to sign anything you like and store the key into the shim somewhere), or something known to the bootloader (which *SHOULD* allow you to sign anything you like and store the key into the bootloader somewhere).
It's a huge, big, complicated muddle to do something that I've never considered in a problem in thousands of deployed desktops, hundreds of servers and dozens of personal machines but that create ENORMOUS problems when it comes to me buying new hardware, booting the OS of my choice, and preventing monopolistic actions by large corporations.
We will see just how many companies ship with the Red Hat key in their BIOS or options to add it / disable signed booting. Until then, no sensible person can really touch that hardware.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 9:54 UTC (Thu) by njwhite (subscriber, #51848) [Link]
Thanks for that explanation, it was very helpful.
> And if you can just add-a-key to the BIOS - which is the standard line about "retaining control" on your PC - why do we need the approval process at all when we could all just enter the relevant key into the BIOS for the OS we want to use?
So we can give a Fedora CD to somebody who doesn't know what a BIOS is, and installing it will Just Work.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 15:39 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
It should, yes. That's one of the primary reasons we are jumping through all these hoops.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 12:56 UTC (Thu) by pbonzini (subscriber, #60935) [Link]
> which is also the only key that needs to be in the PC BIOS (and that's contentious in itself because surely it's up to the manufacturer what keys they use and also how do you update old machines with new keys?
You don't need the shim key in the PC BIOS.
You need the shim to be signed with a key, whose public part is in the PC BIOS. Microsoft runs a signing program which will roughly use the same key used to sign Windows (i.e. you're pretty much sure that the key is in the PC BIOS).
> Everywhere else is signed by something known to the shim (which *SHOULD* allow you to sign anything you like and store the key into the shim somewhere),
It won't allow you, unless you have the shim's private key to do this. Modifying the private key requires one of: 1) asking (paying) Microsoft to sign the new shim; 2) adding your own key to the BIOS, and using it to sign the shim; 3) disabling secure boot altogether.
You cannot use Fedora's shim to run something not signed by Fedora.
> or something known to the bootloader (which *SHOULD* allow you to sign anything you like and store the key into the bootloader somewhere).
Similarly, you will have to sign the new kernel with the bootloader's private key, and you may not have it.
(Actually, to make it more complicated, they will probably provide a mechanism to add keys to the shim. However, it will not be possible for _the kernel_ to do that, so you cannot subvert the chain of trust just by exploiting the kernel. So the kernel can replace the shim/bootloader/kernel, but only with new components whose keys are already trusted).
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 17:14 UTC (Thu) by iabervon (subscriber, #722) [Link]
I believe you're describing how people originally thought it would work. But SuSE's clever idea is that the shim has a method for adding new keys to it; it's kind of like how the BIOS is supposed to allow adding keys, but distros know what the shims UI is like, whereas the BIOS method is probably in some poorly-named menu that's different on every motherboard. It turns out the UEFI has some storage for keys that the shim can write to but nothing later can affect, which means that the shim can trust this storage to only contain what it put in there and not keys that were installed by a rootkit. And the shim manages the keys in accordance with the machine owner's instructions, trusting whatever the machine owner says to trust (and only at boot time, before any code other than the shim has run).
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 23:33 UTC (Thu) by dashesy (subscriber, #74652) [Link]
Thanks for the nice explanation, I was wondering how SuSE's shim is going to save the keys, now it is more clear. Do you know if this safe place is mandatory for all UEFI implementations?
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 23:41 UTC (Thu) by iabervon (subscriber, #722) [Link]
I believe it is, at least for implementations that support Secure Boot. Of course, I don't know if Microsoft or Apple will use them in their boot code, or if Windows or OS X will try to access them post-boot and freak out if that works, so it's possible that it'll be the sort of mandatory feature that doesn't actually work in practice.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 14:30 UTC (Thu) by JEFFREY (subscriber, #79095) [Link]
Thank you for explaining this...
I'll be turning "Secure Boot" off in my UEFI/BIOS settings.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 15:19 UTC (Thu) by theophrastus (guest, #80847) [Link]
Hear hear. and also, Thank you to ledow for the explanation! It helps.
though if anyone wants to make a video involving finger puppets labeled "BIOS", "Bootloader", "Kernel", "Nebulous Signing Authority", and "Feckless User", (handing off to each other a magical onion named "shim"), i would buy 'em a beer.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 10, 2012 20:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> just how often is your kernel compromised on BOOT compared to anything else
As anti-malware and OS security gets better malware is forced deeper into the system. There are already demonstrations of compromising the kernel, boot loader and firmware. Like the Blue Pill reference below it is technically possible to make malware in the lower layers that is undetectable by the higher layers.
> And why did you not just enable BIOS boot-sector protection with a verified-clean bootloader that could do kernel verification for you?
Isn't that a fair description of what Secure Boot accomplishes? All the crypto and key verification are just to make the scheme difficult to subvert, a naive implementation without the crypto could be undetectably subverted.
> It's a huge, big, complicated muddle to do something that I've never considered in a problem
That doesn't mean that there isn't a problem or that this isn't a reasonable solution. This is about trying to fix a whole class of security problem while there still are only a few bits of malware that rely on it. The funny thing about malware, including US-built cyber-weapons, is that as different techniques get discovered entire classes of security problems are detected and anti-malware gets far more sophisticated preventing any of those techniques from being used a second time.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 21:52 UTC (Thu) by vmpn (subscriber, #55435) [Link]
Love the idea of having secure boot. It will make it that much harder for rootkits to be implemented. Especially if one sets all custom keys. So unless owner signs a piece of software with their key it won't boot.
It should be mandatory (and not only on x86/x64) requirement that system owner can set their own keys (all of them if they choose) without any irrevertable change to the underlying HW (E.g. blowing fuses). Then combine that with ability to add new keys via media say USB stick containing keyupdate.sec.efi file signed by valid key. Then you can manufacture readonly media, with the additianl step of uploading the public part of the key (like SuSe proposal for adding keys to shim, but natively supported in UEFI) can be uploaded into secure store that ROM bootloader uses.
But fighting for our rights is hard. Instead of fixing the problem, lets do IT #1 favorite approach. Find an easy "workaround" no matter the consequences. In this case ask M$ a favor of signing distribution keys and hope there won't be conflict of interest (ever).
People will remember these days with regret when we are forced to hack bootloaders of our smart devices (including PCs) like we do with smartphones now. Would you want to report an exploitable bug in the kernel now, or will you hold onto it just in case, so that you can use HW you paid for the way you want.
One giant step backwards for man kind.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 22:06 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
What were your plans for fixing the problem?
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 7, 2012 10:26 UTC (Fri) by paulj (subscriber, #341) [Link]
That sounds almost like a "something must be done, this is something" style of justification for secure boot.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 7, 2012 12:17 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
Well, something *did* have to be done.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 22:51 UTC (Thu) by greennit (guest, #86584) [Link]
Even with that, PCs that come preinstalled with Windows would necessarily have only Microsoft's key installed (since that maximizes security if indeed the user wants to use only Windows).
Selling hardware with a preinstalled OS is the real issue, especially when there are artificial barriers to replacing it.
That's what needs to fought, with the hope that it becomes illegal, or that at least Microsoft and Apple are prevented from doing so.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 23:00 UTC (Thu) by greennit (guest, #86584) [Link]
More precisely, in the case of Microsoft, what needs to be stopped is Microsoft or others giving an incentive to OEMs to preinstall Windows, or preinstall Windows in a certain way.
This includes "Designed for Windows" logo programs, discounts connected to PCs sold with Windows, funding of OEM marketing campaigns, cross-marketing, paying OEMs to install Windows crapware, and so on.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 23:42 UTC (Thu) by dashesy (subscriber, #74652) [Link]
I expect another likely future. Only if a rootkit is smart enough to use just one *unavoidable* bug. I wonder what happens when a system is compromised and rootkit closes the door behind itself, then we may need to hack bootloaders to free ourselves from malware (or maybe use a jtag or resort to some soldering) :)
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 7, 2012 19:12 UTC (Fri) by ballombe (subscriber, #9523) [Link]
This is the plan all along. The NSA pushes for "secure" OS but also creates malwares like stuxnet.
Beside the exploit you are proposing has already been published
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 10, 2012 18:26 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Secure Boot seems to make malware that works like Blue Pill more difficult as it would have to be signed by a trusted authority (MS) and that authority could be revoked by the end user to reliably break the malware that the malware cannot prevent.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 10, 2012 22:12 UTC (Mon) by dashesy (subscriber, #74652) [Link]
Well it also makes it harder to get rid of the malware once it gains the necessary privilege. BTW, apart from a stolen key from some obscure international sound card manufacturer, it takes a few bugs (in kernel of any of the OSes that are signed, and boot loader if there is any in between), for malware to own the hardware. If because of bugs, once that bug is fixed by malware itself, it would be one less path to regain ownership. Considering a malware of such complexity, it would also take quite some time before its presence is detected.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 10, 2012 22:28 UTC (Mon) by raven667 (subscriber, #5198) [Link]
A compromise can only start after you can run user-provided code, you can get to the firmware to the bootloader to the OS kernel safely. Even a signed, user-provided kernel driver that is malware can't break the underlying layers and revoking it or disabling it on boot before it runs would reliably prevent it from being loaded.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 10, 2012 22:47 UTC (Mon) by dashesy (subscriber, #74652) [Link]
Can malware take advantage of the very same mechanism you mentioned to revoke (or modify) the chain of trust to its own advantage? Breaking in one layer at a time. If there is no bootloader (Windows without dual-boot for example), or when same key is used for OS and boot-loader, it means one less layer to break to finally reach the firmware. Even revoking the main kernel could cause a lot of havoc among normal users. I agree, this is fairly hypothetical and very hard to accomplish, but if it happens the blue pill is even stronger with UEFI secure boot presence.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 11, 2012 0:23 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
No, the keys used to determine whether a binary is trusted are not sufficient to produce an authenticated blacklist update. In that scenario you'd expect that the malware would simply block the blacklist updates, but it makes it harder for the malware to spread - you no longer need to ensure that the vulnerable software has been fixed, you just need the key revocation to have occurred.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 11, 2012 5:04 UTC (Tue) by akeane (subscriber, #85436) [Link]
If I can compromise a system to the point of being able to muck about with bootloaders etc. why don't I just replace /bin/login with my own version with a nice backdoor to root instead of all this tedious messing around with shims and the like?
Much easier, and more portable :-)
|
|||||||||||||