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
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:
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.
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?
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/...?
/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.
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:
Thanks!
System details
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: