On Aug 5, 2021, at 9:19 PM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-08-05 at 19:29 -0600, Eric Snowberg wrote:

quoted

quoted

From the thread discussion on 00/12:

Only the builtin keys should ever be on the builtin keyring.  The
builtin keyring would need to be linked to the mok keyring.  But in the
secondary keyring case, the mok keyring would be linked to the
secondary keyring, similar to how the builtin keyring is linked to the
secondary keyring.

      if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
              panic("Can't link trusted keyrings\n");

This part is confusing me though.

Here are some of the tests I’m performing with the current series:

Initial setup:
Create and enroll my own key into the MOK.
Sign a kernel, kernel module and IMA key with my new CA key.
Boot with lockdown enabled (to enforce sig validation).

Kernel built with CONFIG_SECONDARY_TRUSTED_KEYRING=y

$ keyctl show %:.secondary_trusted_keys
Keyring
530463486 ---lswrv      0     0  keyring: .secondary_trusted_keys
411466727 ---lswrv      0     0   \_ keyring: .builtin_trusted_keys
979167715 ---lswrv      0     0   |   \_ asymmetric: Build time autogenerated kernel key: 07a56e29cfa1e21379aff2c522efff7d1963202a
534573591 ---lswrv      0     0   |   \_ asymmetric: Oracle-CA: Oracle certificate signing key: aeefb4bfde095cacaabff81dd266974b1b4e23b8
968109018 ---lswrv      0     0   \_ keyring: .mok
857795115 ---lswrv      0     0       \_ asymmetric: Erics-CA: UEK signing key: 9bfa6860483aa46bd83f7fa1289d9fc35799e93b

With this setup I can:
* load a kernel module signed with my CA key
* run "kexec -ls" with the kernel signed with my CA key
* run "kexec -ls" with a kernel signed by a key in the platform keyring
* load another key into the secondary trusted keyring that is signed by my CA key
* load a key into the ima keyring, signed by my CA key

Kernel built without CONFIG_SECONDARY_TRUSTED_KEYRING defined

$ keyctl show %:.builtin_trusted_keys
Keyring
812785375 ---lswrv      0     0  keyring: .builtin_trusted_keys
455418681 ---lswrv      0     0   \_ keyring: .mok
910809006 ---lswrv      0     0   |   \_ asymmetric: Erics-CA: UEK signing key: 9bfa6860483aa46bd83f7fa1289d9fc35799e93b
115345009 ---lswrv      0     0   \_ asymmetric: Oracle-CA: Oracle certificate signing key: aeefb4bfde095cacaabff81dd266974b1b4e23b8
513131506 ---lswrv      0     0   \_ asymmetric: Build time autogenerated kernel key: 22353509f203b55b84f15d0aadeddc134b646185

With this setup I can:
* load a kernel module signed with my CA key
* run "kexec -ls" with the kernel signed with my CA key
* run "kexec -ls" with a kernel signed by a key in the platform keyring
* load a key into the ima keyring, signed by my CA key

So why would the linking need to be switched?  Is there a test I’m
missing?  Thanks.

It's a question of semantics.  The builtin keyring name is self
describing.  It should only contain the keys compiled into the kernel
or inserted post build into the reserved memory.  Not only the kernel
uses the builtin keyring, but userspace may as well[1].  Other users of
the builtin keyring might not want to trust the mok keyring as well.

Should this feature only work with kernels built with 
CONFIG_SECONDARY_TRUSTED_KEYRING defined?  If so, I could drop support in 
the next version for kernels built without it.