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

Add support automatic Disk encryption (Luks) protected with PCR8 #1737

Open
edcdavid opened this issue May 21, 2024 · 1 comment
Open

Add support automatic Disk encryption (Luks) protected with PCR8 #1737

edcdavid opened this issue May 21, 2024 · 1 comment

Comments

@edcdavid
Copy link

Describe the enhancement

This issue is to discuss ways to better support automatic LUKS disk descryption protected with PCR8 (kernel boot line validation)
The kernel boot line (/proc/cmdline) does not seem to always reflect the current kernel boot line defined in /boot/loader/... . For instance, ostree cleanup and rpm-ostree apply-live would modify /boot/loader/... then only after the host is rebooted, the /proc/cmdline is updated by grub.
The clevis command let users bind disk decryption to TPMv2 PCR registers. PCR register 8 measures the kernel bootline. If a disk is bound to a certain value of the boot line and it changes, it won't unlock unless the same bootline is used. If clevis is used after a call to ostree cleanup, the hash of the kernel bootline recorded in PCR 8 will be calculated based on the old bootloader value. Then when the host reboots and the TPM PCR 8 register is updated, it will not match with the value calculated before reboot and thus preventing disk unlock.
The issue could be resolved by manually rebooting the host to align ostree, grub and the PCR8 hash in the TPM and then run clevis to bind the disk to the correct PCR8 value.

So to automate disk decryption with TPM PCR8, I could see the following solutions:

  1. Disk encryption using PCR8 could be disabled before ostree and grub are aligned. An extra reboot could be triggered to align ostree/ grub and the PCR8 value, then clevis could be used to rebind the disk. Knowing when to reboot would be a issue here since this is usually decided by lifecycle managers not in this scope.
  2. PCR8 is recalculated based on the new boot line value when it is changed by ostree. Maybe a hook in ostree would work for this, or maybe watch ostree systemd logs? A daemon could update the TPM with the new value?
  3. Update clevis to calculate the PCR hash and apply it to the TPM register 8 instead based on the current ostree /boot/loader/... value instead of using the current PCR8 value? How to calculate the next boot line based on the content of /boot/loader/...?
  4. Prevent ostree cleanup and rpm-ostree apply-live when using disk encryption. Cleanup can already be performed automatically before upgrades. see lib/sysroot-deploy: Add experimental support for automatic early prune ostreedev/ostree#2847.

Thanks!

System details

No response

Additional information

No response

@jlebon
Copy link
Member

jlebon commented May 23, 2024

/proc/cmdline reflects the kargs of the current boot. It will never change for the duration of that boot. Naturally, it will differ from what's in /boot/loader/ the minute you need to update settings for the next boot.

I think what you probably want here is a way to hook into ostree so that you can update the digests in the clevis token whenever the bootloader is updated. This is what is being discussed in ostreedev/ostree#1903.

One question is around rollbacks, i.e. if a user selects an older entry in the boot menu. Does clevis support passing multiple allowed digests for a given register? Or probably a reasonable approach there is to just require manual unlocking of the LUKS device.

Also related are UKIs (ostreedev/ostree#2753, #1719) which might be a better fit depending on your use case.

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

No branches or pull requests

2 participants