![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
http://bugzilla.opensuse.org/show_bug.cgi?id=1209006
http://bugzilla.opensuse.org/show_bug.cgi?id=1209006#c30
--- Comment #30 from Joey Lee
From https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/ #m3ce7e451f1855d9c432965bb896cb7ce0f89e009:
The end-user will now need to enroll two keys. First the CA Key into the MOK and then the leaf cert into the secondary trusted keyring.
HOW would the user add this leaf cert? I am not getting it. From the PDF slides I got the impression that the "Root user" would play a role here, but I couldn't figure out how this would work, in particular how the root user's cert would be added to the kernel.
As Michal mentioned, using keyctl. And using keyctl with dracut in initrd to add leaf cert to .ima/.evm or even .secondary_trusted_keys.
Wrt the general mind set, I agree with Michal.
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. 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.
IMO the biggest issue is that IMA is disabled as soon as a .machine keyring is populated. That looks like a political movement of upstream with the intention to deter people from using MoK (and thus, 3rd party modules).
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:
CONFIG_INTEGRITY_MACHINE_KEYRING=y <-- enable .machine keyring
CONFIG_INTEGRITY_CA_MACHINE_KEYRING=n <-- allow all MOK add to .machine
COFNIG_INTEGRITY_TRUSTED_KEYRING=y <-- enable .ima/.evm
CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY=y <-- .secondary
keyring trusted key can be added to .ima/.evm
Enable MokListTrustedRT, looks that the MokListTrusted be set by default after
shim 15.6:
commit 2670c6a17edb239949152c471445fc533d8525aa
Author: Eric Snowberg