On Jul 8, 2021, at 1:31 PM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-07-08 at 11:59 -0600, Eric Snowberg wrote:

quoted

quoted

Asumming a
function similar to "restrict_link_by_builtin_and_secondary_trusted" is
defined to include the MOK keyring, the CA keys in the MOK db would be
loaded onto the MOK keyring, the other keys that meet the secondary
keyring restriction would be loaded directly onto the secondary
keyring[1], and as you currently have, the remaining keys onto the
platform keyring.

This eliminates the exemption needed for loading keys onto the
secondary keyring.  The MOK keyring, containing just CA keys, becomes a
new trust source.

I just want to make sure I understand. If we kept the .mok keyring around, 
we would store it into the system_keyring code, just like the platform 
keyring is stored.  This would allow the move exemption code to be removed.
If the mok keyring is a new trust source, whenever the secondary keyring 
is referenced in verify_ code, the mok keyring will be checked too.  If 
I have this right, let me know and I’ll work on a v2.  Thanks.

All the firmware keys are loaded onto the "platform" keyring, without
any restriction.  Your reference point should be the "builtin" and
"secondary" keyrings, not the "platform" keyring.

Changes:
- defining a new keyring restriction which only allows CA keys to be
loaded onto the MOK keyring.
- defining a new keyring restriction something along the lines of
"restrict_link_by_builtin_mok_and_secondary_trusted()".

In the case of "restrict_link_by_builtin_and_secondary_trusted()", it's
based on a build time option.  In the case of MOK, it might be both a
build time and runtime firmware variable option.  There are quite a few
permutations that will somehow need to be addressed:  secondary keyring
not defined, but MOK keyring defined, and the reverse.

Once all the CA keys in the MOK db are loaded onto the MOK keyring,

To avoid confusion with the new keyring name, would it be more appropriate 
to change what we are calling the .mok keyring to the .trusted_platform 
keyring instead? Or just leave it as .mok?

there will be no need for moving keys to the secondary keyring.  The
secondary keyring restriction will just work.  The main question is
whether there will need to be two passes.   One pass to first load all
the CA keys onto the MOK keyring.  A second pass to load the keys onto
the secondary keyring, based on the keyring restriction, and the
remaining ones onto the "platform" keyring to avoid the regression.

[Once the CA keys are loaded onto the MOK keyring, userspace will be
able to load certificates, signed by a key on the MOK keyring, onto the
secondary keyring.]

Other than that, I think I got it, I’ll start working on a v2.  Thanks.