https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c15 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jlee@suse.com) --- Comment #15 from Martin Wilck <martin.wilck@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.