* Daniel P. Berrangé: >> 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. No, in this model, if you buy a Fedora server, it only boots Fedora until manual intervention. I don't think this is a problem because Secure Boot with that very open signing policy is not very far from disabled Secure Boot. > 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. If Microsoft is confident that their boot path has physical presence checks before destructive operations, they can enable booting from media (even the network by default). That can be used to add powerful recovery tools for their users. Right now, that's risky because pretty much all Linux distributions allow you to create an initrd that wipes all storage media. It's also more likely that you can run code before certain Secure Boot milestones have been rached during the boot process. (And of course it's also possible to impersonate the Windows login screen and log the user's password this.) As far as I understand it, Microsoft has locked down the early boot process to a significant degree (even extending to userspace), so these types of attacks are less likely to be successful in a Windows-only environment. Locking out other bootloaders by default as a defense-in-depth measure doesn't seem so far-fetched to me. Honestly, I had expected this to happen far sooner, and only over time assumed that it would probably never happen for some non-security reasons. Thanks, Florian _______________________________________________ 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
