On 2021-12-21 13:04, Martin Wilck wrote:
I'm missing something essential in the TPM2 scenario. It offers (some) protection against tampering.
Using only PCR 7 does not guarantee a lot; extending the policy to more PCRs will increase the tampering surface protection.
But how does it protect the contents of the storage from being read by 3rd parties? What if someone simply steals the computer and boots it from a USB stick or a DVD? As long as the PCR values are unchanged and she has root rights on the booted devices, the person should be able to read the entire disk. What am I overlooking here?
From the PoC nothing. There are some conflicting goals, but the main one is about the scenario of a server: - If there is non authorized change in the BIOS / UEFI, avoid the boot - If someone steal the HD, makes the data useless The PoC mostly should be covering this use case: for example, there is no password request.
I guess it would work if the kernel, initrd, and kernel command line were also used for PCR-based protection but that's not the setup described in the Wiki, which uses only PCR 7.
Yes, the final policy should be extended to more PCR. Using grub-tpm.efi will enable PCR 8 and 9, that will take care of measure the kernel, kernel command line and the initrd.
I believe the problem could be handled by locking the TPM2 with a password. AFAIK that's possible. But then this password would need to be entered during boot, and I'm unsure whether this is currently supported by the dracut / cryptsetup boot procedure.
I think that can be done, but systemd-cryptenroll can also enroll user provided passwords.
Another remark: the wiki page calls the encrypted boot partition setup the "most secure", but it doesn't mention that GRUB2's cryptomount is painfully slow even on the fastest modern CPUs. I recently tried this (with LUKS1, no TPM), and soon reverted to unencrypted boot because I just couldn't stand having to wait ~30s just for decryption of one LUKS key slot.
Martin