On Thu, Mar 13, 2025 at 2:06 PM aplanas <aplanas@xxxxxxx> wrote: > > On 2025-03-13 10:10, Andrei Borzenkov wrote: > > On Tue, Mar 11, 2025 at 12:17 AM aplanas <aplanas@xxxxxxx> wrote: > > >> [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. > > I would reword it. The attack is possible because we are not checking > the integrity of the device before we give the control to it. > I guess it depends on the objectives. I would like to see a solution that can be enabled by default for an average non-technical user. Both your solution and upstream PR effectively lock users out if something goes wrong. This may be appropriate for a standalone appliance, but for a common desktop installation I want to prevent automatic decryption, not to block the user from accessing his system to repair it. So, I don't really care whether an attacker can enter the fake root or not. I do care that the attacker will not gain access to the encrypted content when doing it. ... > > Right, PCR15 will be changed just when the device is unlocked, but > again, the problem is that there is no order in PCR15 extension. If you > create a policy that adds PCR15 expecting 0x0...0 to unlock root, then > this can work, or not. If you have an encrypted swap, then the value of > PCR15 is not determined unless you impose an order. > Exactly the same consideration applies to your suggested solution. > > Can you ensure that we never ever enter initrd emergency shell? > > Would > > [Unit] > OnFailure=systemd-halt.service > > or > > [Service] > FailureAction=reboot-immediate > > prevent that? > I do not know. Someone intimately familiar with dracut needs to chime in. But see above. I do not think power off in this case is something that should be enabled by default.