Re: systemd-cryptenroll with TPM2

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Tue, Aug 22, 2023 at 10:45 PM Aleksandar Kostadinov
<akostadi@xxxxxxxxxx> wrote:
>
> On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering
> <lennart@xxxxxxxxxxxxxx> wrote:
> > On Di, 22.08.23 19:16, Aleksandar Kostadinov (akostadi@xxxxxxxxxx) 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?