[amluto]

Secure Boot with factory keys has never prevented this attack, by design. You can take a valid, signed OS image from your favorite vendor (Microsoft, Red Hat, whatever), write some userspace code for it that asks for a passphrase and looks exactly like the legitimate paraphrase prompt, and configure the boot order to boot to it. It will pass the Secure Boot checks because it is completely valid. Secure Boot, as configured by default, never had userspace verification as a design goal.

There are at least two solutions:

1. Deploy your own Secure Boot keys and protect them with a firmware password whatever mechanism your particular system has to lock down Secure Boot settings.

2. Use TPM-based security so that even knowing the passphrase doesn’t unlock FDE unless the PCRs are correct.

#1 is a bit of a pain. #2 is a huge pain because getting PCR rules right is somewhere between miserable and impossible, especially if you don’t want to accidentally lock yourself out when you update firmware or your OS image.

Of course, people break PCR-based security on a somewhat regular basis, so maybe you want #1 and #2.

[patrakov]

#2 is also something that a security expert needs to audit, so that booting an extracted stock recovery ISO (which has the kernel signed by the same keys as the real system) does NOT unlock the FDE.

https://discussion.fedoraproject.org/t/issue-with-automatic-...

[amluto]

Right. But this gives a really nasty dilemma:

First, you need a recovery image to be rejected by the TPM rules.

Second, you need an updated image that you prepare yourself, or that the distro prepares, etc, that will respect your security goals (e.g. does not allow you to boot it and copy files off) to be accepted.

Maybe a mainstream distro could distribute a UKI that will unlock a disk and run that disk’s userspace with no safe mode, recovery mode, etc without a password, but I’ve never seen such a thing.