Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initramfs: signature checks #1920

Closed
Plailect opened this issue Oct 3, 2019 · 3 comments
Closed

initramfs: signature checks #1920

Plailect opened this issue Oct 3, 2019 · 3 comments

Comments

@Plailect
Copy link

Plailect commented Oct 3, 2019

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.

@jlebon
Copy link
Member

jlebon commented Jul 13, 2020

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.

@cgwalters
Copy link
Member

This is mostly a dup of #1883

@cgwalters
Copy link
Member

Closing per above

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants