On 6/27/22 13:34, Chris Murphy wrote: > On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Neal Gompa: >> >>> I treat Secure Boot purely as a compatibility interface. We need to do >>> just enough to get through the secure boot environment. >> >> Right. It's not even clear to me why we enforce kernel module >> signatures in Secure Boot mode, and disable a few other kernel features. > > If users can load arbitrary unsigned kernel modules or hibernation > images, it silently circumvents UEFI Secure Boot. I agree this is a > frustrating paradigm for users who want certain features like using > 3rd party modules with a Fedora kernel, or using locked down kernel > features, but I'm not sure what the alternative is. The alternative is to accept that UEFI Secure Boot only provides meaningful security if the default signing keys (in particular, Microsoft’s) are not installed. On Windows, administrator to kernel is not considered a security boundary, so there is no point pretending it is one on Linux if the attacker can just boot Windows. If you are interested in *actual* pre-boot security, I suggest Heads (https://osresearch.net) or at least enrolling your own certificates (which should be sealed to the TPM such that the private keys are only available after successful boot of a signed OS). The initramfs also needs to be signed, and the signature needs to be checked before it is run. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
