Secure Boot
Donate
Complexities and security concerns of Secure Boot in the context of Linux distributions. The challenges posed by Secure Boot's requirement for a single signature on binaries, the reliance on Microsoft's key for booting, and the implications for user trust and security.
Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.
Bad Design[edit]
Secure Boot allowing only one signature on a binary creates a major mess.
1) Users wishing to run in a Secure Boot environment will have to trust Microsoft in order to boot official Fedora. The Secure Boot signing format currently allows only one signature on a binary -- so Fedora's shim bootloader can be signed only by the Microsoft-vouched key. If a user removes Microsoft's key, official Fedora will no longer boot, as long as Secure Boot is on.
Note: Unspecific to Fedora and also applicable to other Linux distributions.
1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware.
But that does not help Ubuntu much because Ubuntu cannot sign its bootloader (shim) with both keys, the Microsoft key and their Ubuntu key. Therefore, quote:
2) Ubuntu CDs, distributed separately from hardware, will also depend on the presence of Microsoft's key in the machine's firmware to boot, when Secure Boot is active.
And also the security gain is negligible because Microsoft's key also must be installed.
1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware. Additionally, they will be required by the certification guidelines to have the Microsoft key installed.
The decision to either trust Microsoft or Ubuntu is a big one. But in rather rare cases it will make sense for users to trust both keys at the same key (except in dual-boot scenarios).
It is also a bit of security theater.
the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel.
Then also nowadays the inital ramdisk used by most (if not all) Linux desktop distributions contains unsigned code.
ExitBootServices
Microsoft[edit]
Microsoft is dictating policy for the Linux boot process.
Due to the complexity of the Linux boot process, the number of active releases from different distributions with compatibility challenges, and the support and serviceability timelines of in-market products, a limited exception to the NX signing requirements has been granted.
This limited exception is granted for shims serving in-market products. This exception will be reviewed regularly, and once component versions are identified that meet the compatibility requirements, new shim signing requests for products targeting the identified components will no longer be exempt. Additionally, when shim functionality is developed to provide compatibility for older, non-compliant boot components, new shim signings will no longer be exempt.
Please reach out to: uefisign@microsoft.com with any questions on this policy.
Related shim ticket linking to the same source Is 15.8 being prepared?
.
There is no single one shim[edit]
There is no "THE shim". Each Linux distribution can compile its own. It is not very useful without getting signed with a key approved by Microsoft. To get reviewed, the shim review board is involved.
https://github.com/rhboot/shim-review
shim HTTP boot[edit]
HTTP boot is part of the UEFI specification.
shim can be started from a UEFI boot entry. [1]
Where is that UEFI boot entry stored? Inside efivars (a (U)EFI variable filesystem).
Where is efivars stored? Inside the NVRAM. What is the NVRAM? Imagine it being similar to a hard drive but not really a separate hard drive. It's a writable storage area on the motherboard, part of the firmware.
shim's HTTP boot can then fetch and execute another UEFI executable such as bootloader (such as GNU GRUB or Linux
The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.
related:
- shim bug report / feature request: remove shim HTTP boot due to security issues / split shim into
shim-trivialandshim-http-boot - shim documentation pull request mention HTTP boot support in readme
Opinion[edit]
Secure Boot is a mechanism imposed by Microsoft (Windows) designed to harm its competition, mostly Linux distributions. Its security properties are moot. Theory and practice. At time of writing:
- Secure Boot in theory: Real Open Source, Linux desktop distributions could have a full verified boot chain and might even have it one day, with user-controlled keys. Perhaps measured boot is more likely to materialize because multiple projects are working towards it. Example projects include systemd (
systemd-measure) (see previous link, watch the linked videos) and heads. - Secure Boot in practice: Just causing user confusion, scaring users, usability issue, way too complicated to use, prevents users from using Linux distributions, causes issues with kernel module installation.
At time of writing, when using Real Open Source Linux desktop distributions, whatever changes on their local system regarding Secure Boot provide practically little relevant security benefit. The bootloader / kernel might be signed with one of the many keys signed by Microsoft, but anything later in the boot process remains unprotected.
Many keys signed by Microsoft: That is, unless the user is proactively studying Secure Boot, removing the Microsoft keys and deploying their own keys, which is a technically difficult process.
To protect the full system, that would be called "full verified boot."
There are no known Open Source Linux distributions working towards Secure Boot or full verified boot, except in so far that they aim to be compatible with a successful boot sequence without the user needing to modify BIOS settings. This is a usability feature and can be called Secure Boot compatibility.
Quote Madaidan's Insecurities, Linux Hardening Guide, Verified Boot:
In general, it's hard to achieve a respectable verified boot implementation on traditional Linux.
This, at time of writing, can be translated to "users will with certainty be unable to achieve full verified boot on Real Open Source Linux desktop distributions."
There are no known developers of such distributions claiming that they have accomplished full verified boot, to the knowledge of the author.
To learn more, the user can read the Verified Boot wiki page, follow its links such as the excellent summary of developments Trusted Boot (Anti-Evil-Maid, Heads, and PureBoot), and watch the linked videos for measured boot.
See Also[edit]
Footnotes[edit]
Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.
A secure by default operating system with the latest security research in place.
At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!