Comment # 32 on bug 1209006 from Martin Wilck

(In reply to Joey Lee from comment #30)

> I agree that the upstream solution is complex, and I do not fully understood
> the Imputed or Transitive concept in their theory. But I think that those
> certificates in db/mok must be differentiated based on functionality
> purpose. The trust is not spread from a purpose to other purposes.

I agree. Especially the distinction between CA keys and code-signing keys and
other "low-level" purposes makes sense (although AFAIK the main reason for
making the distinction is that it allows the certificates lower in the chain to
be invalidated while the CA remains intact).

But I still hold that it the db certificates aren't trusted, you can't trust
anything in the system. A malware-infected firmware could have injected false
certs, keys, and checksums into the kernel before it even starts. Intel TXT had
that concept of a "dynamic root of trust", but TXT wasn't successful, so we're
left with the static root of trust, which is the UEFI db, like it or not.

Or am I missing something? Do modern TPMs provide us with a way to create a
trust relationship which doesn't depend on trusting the firmware?

> Using usage extension in certificates to separate different purposes is a
> strategy. IMA maintainer uses CA in BasicConstraints, digitalSignature and
> keyCertSign to identify CA MOK. And NIAP PPOS certification uses codeSign
> extend key usage. 

That makes sense. But it does not make sense to me that only the CA certs can
be loaded into the machine keyring. Normally you provide the full chain of
certificates that's necessary to verify any given signature. And the full chain
in our case would comprise the code-signing certs as well.

> I have applied Eric Snowberg's patch set on v6.2 kernel and tested. I used
> the following kernel config, and I got a kernel behavior that is similar
> with our downstream patch for modsign:
> 
> ...
> 
> For kernel module sign:
> No difference with our downstream patch, all MOKs be add to .machine keyring
> and link to .secondary_trusted_keys. So all MOKs can be used to verify
> kernel modules.
> 
> For .ima/.evm
> All MOKs can be used to verify keys that will go to .ima/.evm keyrings.

That sounds good. So we could actually use this setup, at least as long as
upstream doesn't enforce CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y.

That said, I still fail to understand what MokListTrustedRT is good for. And if
we "enable it by default", we might as well just shred it, no?