Re: PCR signing / enrolling on UKI and validation by systemd-cryptenroll

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 28.05.24 17:36, Demi Marie Obenour (demi@xxxxxxxxxxxxxxxxxxxxxx) wrote:

> > (you can of course include PolicyAuthorizeNV in the policy you sign
> > for PolicyAuthorize, but that doesn#t work, since we want to pin the
> > local nvindex really, and allocate it localy, and the signer (i.e. the
> > OS vendor) cannot possibly do that. Or you could include the
> > PolicyAuthorize in the policy you store in the nvindex for
> > PolicyAuthorizeNV use, but that feels much less interesting since it
> > means the enforcement of the combination is subject to local,
> > delegated policy choices instead of mandated by the policy of the
> > actual object we want to protect)
>
> Does this work in practice?  I agree that this is ugly, but "ugly" might
> be better than "not working".

Well, it should work. I am still not ready to give up on finding a
better solution to this. For example, I have some vague hopes that we
can make TPM "tickets" work for this.

As I understand tickets would allow us to validate policies once,
which would give us a "ticket" back for that that is valid for a
specific time. Then we can bind the policies of other objects to the
availibility of such valid tickets, and then combine two ticket
validations that way.

Superficially that would do what we need. i.e. if I get one ticket for
the signed PCR policy (i.e. for the PolicyAuthorize thing) and another
ticket for the pcrlock policy (i.e. the PolcyAuhtorizeNV thing) then I
can build a policy checking both tickets and be fine.

Except that things aren't that easy (well, the above isn't precisely
"easy" either), because suddenly a time-out comes into play, and we
lose this nice "fuse blowing" feature of PCRs: i.e. while we boot we
measure the boot phase into PCR 11 after all, to ensure that secrets
that shall only be possible to be unlocked in — let's say – the initrd
cannot possibly be unlocked any later, because the PCR is "destroyed"
via the later phase measurement. If we use tickets we could still
unlock things till the end of the timeout, which we probably have to
pick large because of differences of boot speeds, hence this
compromises security quite a bit I'd say.

Hence, maybe tickets aren't the way to go, they bring complexity, they
would make a pretty relevant feature of our policies go down the drain
– even though they would combine the two relevant policies correctly.

But still, I am not ready to give up, there must be some other way I
think, that I have missed so far.

Lennart

--
Lennart Poettering, Berlin