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 15:21 UTC (Thu) by jake (editor, #205)
In reply to: The Linux Foundation's UEFI secure boot system by pjones
Parent article: The Linux Foundation's UEFI secure boot system

> 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


(Log in to post comments)

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.


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