←back to thread

189 points arjvik | 1 comments | | HN request time: 0.198s | source
Show context
keeperofdakeys ◴[] No.42734325[source]
You can mitigate this by including PCRs that sign the kernel and initrd, however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.

Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.

replies(5): >>42734894 #>>42735137 #>>42735230 #>>42735303 #>>42740249 #
1. Vogtinator ◴[] No.42735303[source]
> You can mitigate this by including PCRs that sign the kernel and initrd.

No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.

> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros. > Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.

With some logic to update the values on kernel updates and re-seal the secret this can be handled transparently. That's the design with sdbootutil in openSUSE (https://en.opensuse.org/Systemd-fde, https://github.com/openSUSE/sdbootutil).