http://bugzilla.opensuse.org/show_bug.cgi?id=1209006 http://bugzilla.opensuse.org/show_bug.cgi?id=1209006#c30 --- Comment #30 from Joey Lee <jlee@suse.com> --- (In reply to Martin Wilck from comment #24)
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 <eric.snowberg@oracle.com> Date: Thu Feb 17 18:29:58 2022 -0500 Allow MokListTrusted to be enabled by default Using keyctl tool shows .secondary_trusted_keys and .machine keyrings, confirmed that MOKs are added and linked: Vigor135:~ # keyctl list %:.secondary_trusted_keys 2 keys in keyring: 727581285: ---lswrv 0 0 keyring: .builtin_trusted_keys 978122164: ---lswrv 0 0 keyring: .machine <-- .machine linked Vigor135:~ # keyctl list %:.machine 7 keys in keyring: 661930310: ---lswrv 0 0 asymmetric: openSUSE Secure Boot CA: 6842600de22c4c477e95be23dfea9513e5971762 46964368: ---lswrv 0 0 asymmetric: openSUSE Secure Boot Signkey: fd9f2c12e599d67cc7f9067541adf426b712469e 119545939: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key11111: 92705a4f4be67f7a90a52166573dd590711f9e32 366702073: ---lswrv 0 0 asymmetric: Kernel OBS Project: 1fb41512acbc8eebdf828d877e4367bf6c719af3 392485614: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: 959b5e1b135628040e10b510443790b327f6615d 820273393: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: 55f24d5835fbedf68734252328b769eb29ddfe97 1055853409: ---lswrv 0 0 asymmetric: Build time autogenerated kernel key: e9454afc180d18db2c0311d43f6fe8dd65cb96e8 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. -- You are receiving this mail because: You are on the CC list for the bug.