On Di, 22.08.23 22:35, Aleksandar Kostadinov (akost...@redhat.com) wrote: > On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering > <lenn...@poettering.net> wrote: > > On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: > <...> > > > If attacker replaces volume with unencrypted one, and it boots without > > > messing up the sealing PCRs, then probably attacker can query the TPM > > > and obtain the encryption key. Despite the fact that this is not (yet) > > > implemented in cryptenroll. > > > > Sure, if you allow unencrypted systems to boot in your OS then all > > bets are off. You shouldn't do that of course. > > > > (in my model of mind, where automatic GPT image dissection is used the > > image dissection policies are how this should be locked down, see > > systemd.image-policy(7). You can confgure that via the kernel cmdline: > > in systemd.image_policy=. > > > > In systemd there's the "systemd-pcrfs@.service" and > > "systemd-pcrmachine.service" which will measure the identity of file > > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > > be an identifier of the OS instance. > > Wait. I was looking at this PCR. But wouldn't it be set only after the > volume has been unlocked? This means that before a volume is unlocked, > it cannot protect anything? Actually it may protect in case where > attacker replaced the volume with another encrypted volume. But not if > attacker replaced with a plain volume.
As I said earlier: if you don't encrypt you lost anyway. This is not a scenario I care about in my view of the world. And frankly, it really doesn't make much sense to try to lock down boot but not actually encrypt the disk... > Or is it measured with the *encrypted* volume key which would actually > protect from volume replacement of any sort (I think) and would mostly > solve my concern? No, we measure the decrypted volume key (or actually, we measure the result of an HMAC of a fixed string, keyed by the volume key, since we don't want the key to show up in measurement logs in any useable way). > I mean if somehow the LVM structure including the encrypted key(s) are > measured somewhere, then such an attack should not be viable. LVM? what's LVM got to do with anything? > I guess I should test whether replacing the volume with non-encrypted > will work. If it works, then there might be an issue. If it does not > work, then sealing with PCR 15 might be what will get me going, > because replacing with an encrypted volume will definitely modify it > and block decrypting of the original key. In my view of the world you have an authenticated + measured UKI that unlocks the encrypted root fs, and simply refuses to boot if the root fs is not encrypted with a key it can acquire somehow. This should give you all the protection you need. Lennart -- Lennart Poettering, Berlin
