User: Password:
|
|
Subscribe / Log in / New account

The Linux Foundation's UEFI secure boot system

The Linux Foundation's UEFI secure boot system

Posted Oct 10, 2012 23:18 UTC (Wed) by pjones (subscriber, #31722)
Parent article: The Linux Foundation's UEFI secure boot system

I don't understand why they didn't build shim with no internal keyring, and have signed, instead of this. That provides a much more compelling system for small distros.


(Log in to post comments)

The Linux Foundation's UEFI secure boot system

Posted Oct 10, 2012 23:47 UTC (Wed) by pjones (subscriber, #31722) [Link]

Should read "and have that signed". Sorry, I was responding on my phone.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 0:50 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

The way I read it the only keyring used is the EFI keyring.

This approach looks very interesting as it allows a transition to a system without Microsoft's key, something that has been lacking in the other efi secure boot approaches I have seen so far.

Thanks James

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 1:17 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

How does it allow a transition away from the Microsoft keys? It depends on the loader being signed with the Microsoft key.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 1:34 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

If I am reading the documentation correctly getting off the windows keys can happen in two ways.

- Booting in setup gives you the option to install the key of the bootloader you are booting into EFI. Presumably that bootloader has not been signed by the Microsoft key.

- There is also another program you can run LockDown.efi that you can run in setup mode that will replace all of the EFI keys.

For more details have a look at the README

http://git.kernel.org/?p=linux/kernel/git/jejb/efitools.git;...

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 1:40 UTC (Thu) by pjones (subscriber, #31722) [Link]

You are not reading the documentation correctly.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 1:43 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

The model is that you'd still be booting the Microsoft signed loader. If you wanted to shift to using your own hash you'd need to rewrite the boot entry to stop running that, and then it'll stop booting if the bootloader ever gets updated since it registers the hash, not a key. This doesn't offer anything you're not already guaranteed to be able to do via the firmware.

(I've read the code, thanks. I wrote most of it)

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 3:50 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

Is there a way to change the EFI keys programatically? So that you don't need to go through an EFI user interface that is likely to be different on different motherboards to change the keys?

If you can't get to the point making it an option to disable Microsofts key what is the point?

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 4:14 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

The only way to modify the EFI key databases programmatically is to have access to the private half of one of the keys in the KEK database, which then allows you to produce signed updates to DB (the key and hash whitelist) and DBX (the corresponding blacklist). The only people who will typically have that are Microsoft and, perhaps, the motherboard vendor. If you want to modify those databases without having access to a key then you need to go through the firmware interface.

That's the reason for the MOK design that Suse came up with. It adds an additional key database that has different constraints, permitting users to add their own keys without having to handle different firmware UIs. I've recently added bootloader-level UI code for this (located at https://github.com/mjg59/shim/tree/mok ), which means that the end user can be prompted to enrol a new key at boot time without having to deal with firmware UI. The Linux Foundation approach doesn't support this, and as a result is pretty much useless.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 14:24 UTC (Thu) by jake (editor, #205) [Link]

> The Linux Foundation approach doesn't support this, and as a result is
> pretty much useless.

But, something the LF approach will do, that the shim won't (if i understand correctly), is boot an unsigned bootloader/kernel ... albeit after the user presses "OK" or whatever ... right now, for a distro that doesn't want to deal with signing their GRUB2 (or whatever) and/or their kernels, they have no way to boot in a secure-boot-enabled device.

Or am I (as usual) missing something?

jake

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 14:28 UTC (Thu) by pjones (subscriber, #31722) [Link]

No - that's in fact the entire point of SuSE's "MOK" system. Current shim will allow you to enroll a key or hash with physical presence during system bootup. So what shim with an empty internal key list gets you is analogous to this plan, except with this plan you have to be physically present every time, and with shim you only have to be there /once/.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 14:40 UTC (Thu) by jake (editor, #205) [Link]

> So what shim with an empty internal key list gets you is analogous
> to this plan

Ah I see, thanks for the info ... does that mean that when I want to boot a LiveCD (say), I have to write stuff (even "empty" stuff) to the UEFI boot variables of the machine? Or can shim just bypass all of that and, in effect, provide the same "always present user" boot style that the LF approach takes? At some level, I guess I am asking if shim is a complete superset of the LF approach.

There may be times or reasons that someone booting doesn't want to write to the firmware of the box ...

jake

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 14:57 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

We're pretty reluctant to just add the "Press y to continue" code because that's something Microsoft explicitly forbid from being present in the system firmware, and there's a pretty strong incentive to be conservative. Adding the functionality would be trivial, it's really a policy thing.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 15:21 UTC (Thu) by jake (editor, #205) [Link]

> So what shim with an empty internal key list gets you is
> analogous to this plan

Hmm, thinking further on this, what does having an "empty internal key list" actually mean? I assume it means that something gets written to the firmware in the MOK boot variable area. Does that wipe out my existing MOK keys? or just allow unsigned booting forevermore?

I have a Fedora secure boot system installed, with its key in the MOK, now I want to boot JRandom LiveCD. It has an unsigned second-stage bootloader (GRUB2 or equivalent) and unsigned kernel. Can it use shim as its first stage? It would seem that either that would mean I lose my Fedora key in the MOK or I add an empty key that allows anything to boot thereafter. But if it uses the LF first-stage, it can boot (after I press OK) and not change the state of the system.

Or have I got that wrong?

thanks!

jake

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 15:29 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

The shim design effectively has three databases to validate against:

1) The UEFI spec database (db) - this is checked in order to conform to the spec
2) The MOK database - this is checked in order to allow users to modify their trusted keys without having to use firmware-specific UI
3) A built in database - this is baked in at build time. The idea here is for the distribution to include their public key in shim when they build it, and after that shim will trust any binaries built and signed by that distribution.

So, for instance, the Fedora shim will have the Fedora key in (3). If the idea is to leave control up to the user then leaving (3) empty achieves that.

This actually allows for some interesting possibilities. If a vendor wants to set up a Linux CA (which would be expensive to do properly, and potentially open to legal risks, but it *could* be done) then they could do this by simply embedding their key in (3) and getting that copy of shim signed by Microsoft. They could then provide keys that chain back to the key in (3) to whoever was interested, using whatever policy they wanted. This is a great deal easier than getting their key into every platform's firmware, but means that an overly lax security policy could result in blacklisting by Microsoft. We'll see if anyone decides to make that happen.

The Linux Foundation's UEFI secure boot system

Posted Oct 11, 2012 15:14 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

Is there a way to change the EFI keys programatically?
There shouldn't be a way of doing this programatically, since it undermines the whole point of the secure boot system. The goal of the system is to make sure that you can't run unsigned code without user intervention. If you could bypass the secure boot without user intervention, then malicious code could do exactly the same thing and the system would be worthless for preventing boot sector malware. The goal of all these open source approaches to secure boot is to let open source take advantage of the real benefits of the system.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds