Comment # 30 on bug 1209006 from Joey Lee

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