Re: systemd-cryptenroll with TPM2

[Aleksandar Kostadinov <akostadi@xxxxxxxxxx>]

On Wed, Aug 23, 2023 at 10:49 AM Andrei Borzenkov <arvidjaar@xxxxxxxxx> 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?
>