Comment # 15 on bug 1209006 from Martin Wilck

(In reply to Joey Lee from comment #9)

> > In upstream the MOK keys are loaded into machine keyring which then should
> > get loaded into secondary keyring.
> 
> Looks it's not. 
> 
> Base on v6.2 kernel, keys in .machine keyring still must be trusted(signed)
> by key in built-in/secondary keyring. It applies restrict_link_to_ima and
> depends on CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY.

system_trusted_keyring_init() uses get_builtin_and_secondary_restriction() as
restriction for the secondary keyring. This resolves to 
restrict_link_by_builtin_secondary_and_machine() if
CONFIG_INTEGRITY_MACHINE_KEYRING is set, (and
restrict_link_by_builtin_and_secondary_trusted otherwise).

But machine_keyring_init() -> integrity_init_keyring() ->
_integrity_init_keyring() uses restrict_link_to_ima, which resolves to
restrict_link_by_builtin_and_secondary_trusted(). 

So keys could be added from the machine keyring to the secondary keyring
without being trusted by the secondary keyring beforehand, but such keys could
never have been added to the machine keyring in the first place.

That looks like an upstream bug to me.

TBH, I fail to understand the entire concept. A users's key will always be
self-signed, or at best signed by the user's own CA. How would the user be able
to have it signed by any key in the builtin or secondary keyrings, without
compiling the kernel with her own key?

(Side note, off-topic: I also fail to understand why the kernel doesn't accept
pre-boot keys for signing modules. In the past it was possible to have hardware
vendor keys (such in Dell) in the EFI db and use them for verifying
vendor-provided 3rd party modules. Which was not a bad idea, IMHO. I sounds
hypocritical to me not to trust the db keys. If those were compromised, the
entire enviroment the kernel was running in would be compromised already).

> So, currently the .machine keyring is NOT useful for loading a MOK-signed
> kernel module. I think all MOKs will be loaded to .platform keyring. Unless
> Eric Snowberg's MOK CA patch be accepted:

Not sure what that patch would change in this respect, except placing
additional restrictions on the keys that would be accepted.

Can you explain how the CA restriction is supposed to work (assuming the issue
above is fixed somehow) ? Only CA certs from the MoK will be added to the
machine and secondary keyrings. But how will the user sign the modules then? In
the strictest form, the CA certs are not permitted to have the
"digitalSigature" usage flag set. Thus AFAIK they can't be used to sign kernel
modules. An intermediate cert would be needed which would be signed by the CA,
and then used to sign the modules. But how would that intermediate cert be
loaded into the kernel? IIUC it would end up in the .platform keyring which is
_not_ used to verify modules...

> Kernel will check the existence of MokListTrustedRT. So we need to run
> "mokutil --trust-mok", otherwise all MOK will go to .platform keyring.

This seems weird to me too. Why would a user put a key in the MoK if she didn't
want the kernel to trust it? It just adds extra inconvenience (having to run
"mokutil --trust-mok"), but zero extra security, AFAICT.