On Tue, Mar 11, 2025 at 12:17 AM aplanas <aplanas@xxxxxxx> wrote: > > On 2025-03-10 19:04, Adrian Vovk wrote: > > > Presuming a system like this: > > - We've got a Linux desktop system > > - We have two dm-verity protected /usr partitions > > - We have one encrypted rootfs > > - We're using systemd-repart to create the rootfs on first boot > > - The rootfs is automatically unlocked by the initrd, at boot, using > > the > > TPM. We're using systemd-pcrlock with a PCR 11 signature > > - We're making use of systemd-pcrphase, and the rootfs is unlockable > > _only_ > > during `enter-initrd`. Once we hit `leave-initrd`, the rootfs is no > > longer > > unlockable. This means that the rootfs is only unlockable in the > > initrd. > > If this a good idea in general? This makes impossible to update the > NVIndex policy automatically via the recovery PIN. You need to ask the > user for the PIN after each new make-policy. > Nothing prevents using different policies for NVIndex. > > Here's a potential attack: > > It is very similar to the original one published some months ago[1], and > the one described in the other thread. All three boils to the same > topic, the measure boot is stopping in the initrd and we need a way to > authenticate the device before delegating the execution. Just continue > the measure boot one extra step. > > [1] https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ > This attack is possible because root is bound to the boot time TPM state that is not modified after the system is booted. To mitigate this, the root has to be additionally bound to some run-time state that only allows unlocking during the specific boot stage. Whether it is PCR11 for pcrextend or PCR15 for other filesystem or something else doesn't really matter. But PCR15 looks better - it will be automatically set as soon as the (fake) root is unlocked, thus changing run-time state for any subsequent attempt to mount the real root. The default setup of pcrextend does not help here - we only do it entering and leaving initrd, so inside initrd there is no state change after the (fake) root was unlocked. Thus the scenario with multiple filesystems inside initrd is still vulnerable. > The solution presented there will resolve the three instances of this > attack. You just need to measure the vk of each device that is in the > initrd's /etc/crypttab in an ordered way and halt the system from the > initrd if the value is not the expected one. systemd could do that, but > if not it is not hard to implement [2] > > [2] > https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.service > Can you ensure that we never ever enter initrd emergency shell? This is yet another vector - let dracut fail the root mount but still unlock the other LUKS volume. And if we consider the possibility of spoofing TPM communication - the values are in clear text and so can be spoofed (as long as it is technically possible at all). I suppose it can be improved by encrypting via TPM.