On Fri, Jul 29, 2022 at 11:26:15AM +0200, Florian Weimer wrote: > * Vitaly Zaitsev via devel: > > > On 26/07/2022 20:05, Chris Murphy wrote: > >> Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result: > > > > Microsoft has published a new security bulletin on the current state > > of Secure Boot: > > https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process > > > > The most important note: > > > >> Secured-core PCs require Secure Boot to be enabled and configured to distrust the Microsoft 3rd Party UEFI CA signature, by default, to provide customers with the most secure configuration of their PCs possible. > > > > TL;DR. The new certified by Microsoft devices will be able to load > > only Microsoft Windows in the UEFI Secure Boot enabled mode. > > > > "Microsoft <3 Linux", "Microsoft is a friend", "Microsoft has > > changed", - they said. > > But they also say this: > > | The default state of Secure Boot has a wide circle of trust which can > | result in customers trusting boot components they may not need. Since > | the Microsoft 3rd Party UEFI CA certificate signs the bootloaders for > | all Linux distributions, trusting the Microsoft 3rd Party UEFI CA > | signature in the UEFI database increase[]s the attack surface of > | systems. A customer who intended to only trust and boot a single Linux > | distribution will trust all distributions–much more than their desired > | configuration. > > And this is an accurate description of the situation. > > Unfortunately, Fedora promoted this broken model with pervasive > cross-distribution/cross-OS trust as well. People are generally quick > to criticize those who control a PKI, but very few organizations are > willing to step up to hold the key material for the key of last resort > because of the risk inherent to that. Consequently, pretty much all > distributions hide behind the Microsoft key, instead of running their > own PKI and working with OEMs to get it accepted by the firmware. Would the situation actually be any different in that case ? Assume an alternate reality where hardware OEMs magically agreed to pre-install 20 different keys for the various Linux vendors. You still have the same "problem" that you're running 1 specific vendor's OS, but your firmware trusts the software from countless different unrelated vendors for SecureBoot. Either way though, IIUC, this ought not to be a problem if combining SecureBoot with TPM measurements. The firmware measures the SecureBoot signing key of the OS binary that is booted into PCR 7. So if BitLocker keys are tied to PCR-7 when it was booted with the Microsoft Windows UEFI CA, then any attempt to boot an OS signed by the Microsoft 3rd Party UEFI CA would get different PCR-7 measurements and so BitLocker keys are safe. On the Linux side, IIUC shim will measure the certificate that signed the Linux OS it loads into PCR-7 too. So if the Linux guest ties LUKS keys to PCR-7, then again it should be secure[1] against someone trying to boot a different Linux vendor's OS. With regards, Daniel [1] I'm ignoring the inconvenient initrd hole that exists in more or less all Linux OS wrt boot measurements. That's a technical impl flaw, rather than an inherant problem of the SecureBoot/TPM techology. -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
