[systemd-devel] systemd-cryptenroll with TPM2

[Andrei Borzenkov]

On Wed, Aug 23, 2023 at 12:50 PM Aleksandar Kostadinov
<akostadi at redhat.com> wrote:
>
> On Wed, Aug 23, 2023 at 10:49 AM Andrei Borzenkov <arvidjaar at gmail.com> 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 at .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?
> >
>