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 11, 2012 3:50 UTC (Thu) by ebiederm (subscriber, #35028)
In reply to: The Linux Foundation's UEFI secure boot system by mjg59
Parent article: The Linux Foundation's UEFI secure boot system

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?


(Log in to post comments)

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