On Thu, Apr 7, 2022 at 8:28 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Di, 05.04.22 17:38, Chris Murphy (lists(a)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.
--
Chris Murphy