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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 28.05.24 21:21, Andrei Borzenkov (arvidjaar@xxxxxxxxx) wrote:

> On 28.05.2024 17:49, Lennart Poettering wrote:
> >
> > systemd-cryptenroll supports pin, literal PCR, signed PCR — in any
> > combination. (plus pcrlock, but that's currently cannot be combined
> > with signed PCR, because afaics not expressible in the TPM policy language).
> >
>
> Why not? You can AND pcrlock with other policies just like currently literal
> PCR is ANDed with signed PCR. You can even use signed PCR in pcrlock policy
> - PolicyOR does not care what policies are combined, literal PCR (like is
> done currently) or signed PCR. Or what semantic do you have in mind that
> cannot be expressed?

pcrlock is ultimately a PolicyAuthorizeNV policy, and signed policies
use PolicyAuthorize. Both of these policy items do not *extend* the
policy so far enqueued, but *replace* it instead. (This is different
from policies such as PolicyPCR or PolicyAuthValue and so on, which
result in extension, i.e. "AND") Thus, there's not directly obvious
way how you could combine them.

(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)

I have so far not found a nice way out of this problem. Seems to be a
limitation of the TPM policy language.

Lennart

--
Lennart Poettering, Berlin