A Modern Look at Secure Boot
James Bottomley
jejb@kernel.org
@jejb@mastodon.online
About Me
Container evangelist
Open Source Advocate
- Converting Business to Open Source
- Lead effort to create LF TAB
Kernel Developer
- SCSI Subsystem Maintainer
- PA-RISC architecture Maintainer
Also wrote the first Secure Boot loader PreLoader in 2011
Pieces of which are still in shim today
Still Maintain efitools and sbsigntools and represent Linux on UEFI SST.
History
Microsoft mandated secure boot for PCs in 2011
Initial Linux concern was exclusion from the PC market
Microsoft assured us this wasn't the goal
So I wrote and got PreLoader
signed to test that
shim came along in 2012
And the MOK (Machine Owner Key) in 2013
shim/MOK is now our standard Linux Secure Boot mechanism
What is Secure Boot?
When activated the system won't execute anything from UEFI unless it's signed by the UEFI CA key
Can be deactivated by disabling Secure Boot in the BIOS menus
Implemented as a set of keys and hashes in the Authenticated Variable Database db
Revocation accomplished by blacklisting keys and hashes in dbx
Updates to db and dbx can be done by an update signed by a key in the Key Exchange Key Database KEK
Updates to KEK can only be done if signed by the Platform Key PK
db, dbx and KEK are all lists but PK may only contain one key
You "Take Ownership" of your platform by replacing PK
shim and MOK
shim pivots trust away from the UEFI keys
All shim variables are persistent but boot time only (invisible to OS)
On boot, shim copies the variables to runtime visible but volatile variables suffixed with RT (so the OS can see them).
Keys in MokList are used to verify onward boot
Keys and hashes in MokListX are used for revocation
On boot, the kernel populates the %:.platform keyring with the UEFI db keys
and %:.machine with the MokListRT keys
Keys are enrolled in MokList using a password protected handshake protocol via the MokNew variable
Done under the covers via
mokutil --import file
mokutil --import file
Kernel Trusted Keyrings
By default, the kernel only trusts it's compiled in key in %:.builtin_trusted_keys
But it is usually configured also to trust the MokList keys
total list of trusted keys is always in %:.secondary_trusted_keys
Some distributions (Fedora) also have an out of tree hack to add the db keys to this (but most don't)
Keys the kernel trusts can be used to sign modules
Problem: if you turn off secure boot, %:.machine won't be populated
Revocation and SBAT
The UEFI revocation story is absolutely abysmal
Blacklisting single binaries by hash simply doesn't scale
If we discover an exploitable flaw in one of our boot components, we want to blacklist it and all its predecessors
The SBAT mechanism does this
Each EFI binary has a .sbat section consisting of a tag and a level
There's a global tag sbat currrently at level 1
Upstream app specific tag (grub for grub etc)
and a distro specific tag (usually app.distro)
Shim itself sets the global SbatLevel variable
If any tagged level in .sbat is found to be less than the same value in SbatLevel the binary is forbidden
can revoke classes of binary by raising the level in SbatLevel
Revoke everything by raising sbat or simply revoke a single distro version by raising app.distro
Mechanism is very granular and doesn't wast NVRam space (unlike dbx)
Demo
Conclusions
Secure Boot is now an indispensible part of our modern security tools
MOK variables are used to populate trusted keys for the kernel
Beware of misbehaviour when secure boot is disabled
Revocation is nicely handled by SBAT
Web Developer!
Thank You!
Questions?