On Thu, Apr 7, 2022 at 8:28 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Di, 05.04.22 17:38, Chris Murphy (lists@colorremedies.com) wrote:
When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*.
Let me stress one thing though: Fedora *has* *no* working SecureBoot implementation. The initrd is not authenticated. It has no signatures, nothing.
By disabling SecureBoot you effectively lose exactly nothing in terms of security right now.
What good is a trusted boot loader or kernel if it then goes on loading an initrd that is not authenticated, super easy to modify (I mean, seriously, any idiot script kiddie can unpack a cpio, add some shell script and pack it up again, replacing the original one) – and it's the component that actually reads your FDE LUKS password.
I mean, let's not pretend unsigned drivers were a big issue for security right now. They are now, we have much much much wider gaping holes in our stack.
I agree that the lack of a signed initrd is a big gaping hole. I don't agree it's pointless to ensure the bootloader, kernel and kernel modules are authentic. It's bad to have malware running in user space. It's extra bad if it's running in kernel space. There are examples of such malware, including lie in wait, that can embed maleware into SPI flash once Secure Boot is disabled. Even if you were to discover this (difficult considering most vendors aren't publishing hashes of their firmware) you'd basically be screwed, not even replacing the boot drive would get rid of it.