On Wed, May 29, 2024 at 10:36:28AM +0200, Lennart Poettering wrote: > 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. What about inserting an explicit delay into the boot process until the ticket expires? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
