Linux Security Modules development

* Re: [PATCH RFC 00/12] Enroll kernel keys thru MOK
From: Eric Snowberg @ 2021-07-08 23:17 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: keyrings, linux-integrity, David Howells, David Woodhouse,
	Herbert Xu, David S . Miller, Jarkko Sakkinen, James Morris,
	Serge E . Hallyn, keescook, gregkh, torvalds, scott.branden,
	weiyongjun1, nayna, ebiggers, ardb, nramas, lszubowi,
	linux-kernel, linux-crypto, linux-security-module,
	James.Bottomley, pjones, glin, konrad.wilk@oracle.com
In-Reply-To: <490941a5197bf4bcf0d6f95610085ee4d46ed9bb.camel@linux.ibm.com>

> On Jul 8, 2021, at 1:31 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Thu, 2021-07-08 at 11:59 -0600, Eric Snowberg wrote:
>> 
>>> 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.

^ permalink raw reply