I am a big fan of PCR signatures these days. Changed my mind 180° on that.
PCR 7-based policies are not that easy to deploy, if you at the same time let fwupd update dbx as part of its firmware upgrade routines (and thus the secureboot policy). I probably should add a note to our docs about that. Because that means fwupd would change PCR 7 values regularly (and you cannot sign the expected values because laptops have keys enrolled specific to the vendor). So for now I’d step away from PCR7 based policies. This needs more preparation in systemd first.
I think what you can do is PCR 11 based policies for now. I’d envision it like this: fedora would create a signing keypair. Each time fedora builds a kernel it would include a “.pcrsig” PE section that contains a signature for the expected PCR 11 value in the boot phase where the rootfs shall be unlocked (i.e. in the initrd), generated with that key. Then, fedora would enroll the rootfs to that public key and thus have a rootfs that can only be unlocked on fedora, from the initrd.
(it might make sense to generate a second keypair at the same time, and sign with it the PCR 11 values expected on that kernel for the boot phases expected during regular runtime too. This should be used for auxiliary encrypted volumes, i.e. not the rootfs but anything else that is activated from later boot or on demand, instead of from the initrd like the rootfs).
PCR 4-based policies are probably out of scope for now too, we also need more infrastructure to make that happen. We probably have to predict changes like Windows does, and then hook into that from fwupd and from boot loader updater (bootctl) or so. It’s a mess, and nothing has been done.
So, under the assumption you stick to PCR 11 based policies for now, there are two attack vectors I see, that we need to address sooner or later.
-
the rollback thing matthew mentioned: we need to cut off old versions of the OS regularly so that people cannot attack the disk encryption by booting old versions of the OS. See above for our ideas on that. No code exists.
-
right now the systemd efi stub that measure the kernel it is about to boot to PCR 11 does so knowing that it is the only user of that PCR. Which is great. But it also means that if you boot through shim, then anything else booted through shim will see an all zero PCR 11, and then can manually measure whatever it wants into PCR 11 and fake the values we expect only to see if a valid fedora UKI kernel is booted. (This vulnerability is not specific to sd-stub btw, IMA has the same weakness, afaics). A fix to this is technically easy, but I didn’t want to deal with the politics of this: shim should probably just measure a string derived from the payload it is about to boot into all PCRs that are not used by itself or by the firmware, including PCR11.That way, shim payloads cannot easily fake each other’s PCR values.