You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, standard Fedora installations do not verify the integrity of the initramfs images even when booting under UEFI Secure Boot, allowing for its security benefits to be trivially circumvented as untrusted code can be executed as root in early boot by simply modifying the initramfs image.
Since the infrastructure for doing securing the initramfs client-side would be potentially difficult (generating and protecting machine-unique signing keys, etc.), this limitation has made sense up until now. With Silverblue's default server-side initramfs generation, there is an opportunity to solve this issue by shipping an initramfs image signed by official Fedora keys (which would be enforced by the Fedora signed kernel binary, which is in turn verified by Shim signed by either Microsoft's keys or the user's keys).
This would likely also require securing the kernel command line arguments / GRUB2 in some way (which may also prove to be somewhat difficult) to be entirely effective, but this would allow for the (ideal) future possibility to ship secure-by-default installations which transparently decrypt a LUKS encrypted drive using TPM2/Secure Boot verification with latchset/clevis (another RedHat project) much as Microsoft has been doing for years with Bitlocker.
The text was updated successfully, but these errors were encountered:
Thanks for opening this! I agree this would be great.
A lot of kinda related work on this is happening in Fedora CoreOS, where we're working on adding support for rootfs-on-LUKS with Clevis binding. The topic of trusted boots came up a few times in those discussions.
Since the infrastructure for doing securing the initramfs client-side would be potentially difficult (generating and protecting machine-unique signing keys, etc.), this limitation has made sense up until now.
One tricky bit about this is that rpm-ostree does also support regenerating the initramfs locally, so I think we would probably still have to address this case too.
Currently, standard Fedora installations do not verify the integrity of the initramfs images even when booting under UEFI Secure Boot, allowing for its security benefits to be trivially circumvented as untrusted code can be executed as root in early boot by simply modifying the initramfs image.
Since the infrastructure for doing securing the initramfs client-side would be potentially difficult (generating and protecting machine-unique signing keys, etc.), this limitation has made sense up until now. With Silverblue's default server-side initramfs generation, there is an opportunity to solve this issue by shipping an initramfs image signed by official Fedora keys (which would be enforced by the Fedora signed kernel binary, which is in turn verified by Shim signed by either Microsoft's keys or the user's keys).
This would likely also require securing the kernel command line arguments / GRUB2 in some way (which may also prove to be somewhat difficult) to be entirely effective, but this would allow for the (ideal) future possibility to ship secure-by-default installations which transparently decrypt a LUKS encrypted drive using TPM2/Secure Boot verification with latchset/clevis (another RedHat project) much as Microsoft has been doing for years with Bitlocker.
The text was updated successfully, but these errors were encountered: