Re: [systemd-devel] systemd-cryptenroll with TPM2
On Wed, Aug 23, 2023 at 12:50 PM Aleksandar Kostadinov wrote: > > On Wed, Aug 23, 2023 at 10:49 AM Andrei Borzenkov wrote: > <...> > > > > 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. > > > > > > > I try to understand this threat model. > > > > System will have kernel and initrd which are measured. Initrd will be > > configured to require encrypted volume with specific UUID. So if this > > encrypted volume is not available, booting fails. What happens depends > > on the exact initrd implementation. With dracut I think it will just > > hang indefinitely. > > > > So to boot into plain volume one needs to either replace initrd which > > invalidates measurements or use explicit command line parameters to > > override root device which hopefully is measured as well and so > > invalidates the measurements too. > > When I looked previously into clevis' initrd integration, my > recollection is that it would allow booting from unencrypted volume if > volume was unencrypted (but might be wrong). And it would try to Do not confuse different layers. Clevis is a tool to automatically decrypt (LUKS) volumes. What happens if clevis did not decrypt anything is beyond the scope of clevis. > unlock only if it found an encrypted volume. i.e. if one supplied an > unencrypted root volume with the same id as the encrypted one (and one > can obtain this id without decrypting the volume as it should be in > bootloader config already), clevis would not complain that it unlocked > nothing. Thus allowing to boot an attacker controlled system with PCRs > in a state suitable to decrypt the original volume encryption key. > It depends on how exactly the root device is looked for, but yes, if UUID is used it is possible to create a filesystem with the same UUID. And initrd or UKI are not encrypted and are in ESP. > From your reaction I assume this would not be possible with > systemd-cryptenroll. Correct? It is completely unrelated to systemd-cryptenroll. As I said, it depends on what code inside initrd is doing. > I guess I have to do my homework and try it out. Although I know > little about how it works. So failing to trick it into booting with > unencrypted volume (without modifying initrd and kernel cmd) will not > be proof that it's impossible. > > Does my concern make more sense now? > Yes, it does. > > If initrd drops into the shell when the root device is missing then it > > could indeed offer the possibility to obtain a secret key. One > > possible mitigation is to extend PCR when an interactive shell is > > entered. > > I didn't think about this but it's another thing to consider. I > thought that with secure boot enabled, initrd should not fall into a > shell. But I haven't tried that. > Basically initrd should either never fall into a shell or should > cripple at least one pinned PCR to prevent such an attack vector. > > > Or do you have something different in mind? > > >
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Wed, Aug 23, 2023 at 10:49 AM Andrei Borzenkov wrote: <...> > > > 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. > > > > I try to understand this threat model. > > System will have kernel and initrd which are measured. Initrd will be > configured to require encrypted volume with specific UUID. So if this > encrypted volume is not available, booting fails. What happens depends > on the exact initrd implementation. With dracut I think it will just > hang indefinitely. > > So to boot into plain volume one needs to either replace initrd which > invalidates measurements or use explicit command line parameters to > override root device which hopefully is measured as well and so > invalidates the measurements too. When I looked previously into clevis' initrd integration, my recollection is that it would allow booting from unencrypted volume if volume was unencrypted (but might be wrong). And it would try to unlock only if it found an encrypted volume. i.e. if one supplied an unencrypted root volume with the same id as the encrypted one (and one can obtain this id without decrypting the volume as it should be in bootloader config already), clevis would not complain that it unlocked nothing. Thus allowing to boot an attacker controlled system with PCRs in a state suitable to decrypt the original volume encryption key. >From your reaction I assume this would not be possible with systemd-cryptenroll. Correct? I guess I have to do my homework and try it out. Although I know little about how it works. So failing to trick it into booting with unencrypted volume (without modifying initrd and kernel cmd) will not be proof that it's impossible. Does my concern make more sense now? > If initrd drops into the shell when the root device is missing then it > could indeed offer the possibility to obtain a secret key. One > possible mitigation is to extend PCR when an interactive shell is > entered. I didn't think about this but it's another thing to consider. I thought that with secure boot enabled, initrd should not fall into a shell. But I haven't tried that. Basically initrd should either never fall into a shell or should cripple at least one pinned PCR to prevent such an attack vector. > Or do you have something different in mind? >
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Tue, Aug 22, 2023 at 10:45 PM Aleksandar Kostadinov wrote: > > On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering > 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. > I try to understand this threat model. System will have kernel and initrd which are measured. Initrd will be configured to require encrypted volume with specific UUID. So if this encrypted volume is not available, booting fails. What happens depends on the exact initrd implementation. With dracut I think it will just hang indefinitely. So to boot into plain volume one needs to either replace initrd which invalidates measurements or use explicit command line parameters to override root device which hopefully is measured as well and so invalidates the measurements too. If initrd drops into the shell when the root device is missing then it could indeed offer the possibility to obtain a secret key. One possible mitigation is to extend PCR when an interactive shell is entered. Or do you have something different in mind?
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Di, 22.08.23 22:35, Aleksandar Kostadinov (akost...@redhat.com) wrote: > On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering > 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
