[PATCH RFC v2 00/12] Enroll kernel keys thru MOK

[Eric Snowberg]

> On Aug 3, 2021, at 7:14 PM, Mimi Zohar <zohar at linux.ibm.com> wrote:
> 
> On Tue, 2021-08-03 at 13:52 -0600, Eric Snowberg wrote:
>>> On Aug 3, 2021, at 11:01 AM, Mimi Zohar <zohar at linux.ibm.com> wrote:
>>> 
>>> On Mon, 2021-07-26 at 13:13 -0400, Eric Snowberg wrote:
>>> 
>>>> When the kernel boots, if MokListTrustedRT is set and
>>>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
>>>> mok keyring instead of the platform keyring. Mimi has suggested that
>>>> only CA keys or keys that can be vouched for by other kernel keys be
>>>> loaded into this keyring. All other certs will load into the platform
>>>> keyring instead.
>>> 
>>> I suggested only loading the CA keys stored in the MOK db onto the MOK
>>> keyring.  Like the builtin trusted keyring, the MOK keyring would also
>>> be linked to the secondary keyring.   Assuming the secondary keyring is
>>> defined, all other properly signed MOK db keys  - signed by keys on the
>>> builtin, secondary or MOK keyring - would be loaded onto the secondary
>>> keyring.
>>> 
>>> As previously discussed, this might require reading the MOK db twice -
>>> once to load the CA keys on the MOK keyring, a second time to load the
>>> remaining properly signed keys onto the secondary keyring.
>> 
>> I’m only loading CA keys or keys that can be vouched for by other kernel 
>> keys into the new mok keyring.
> 
> The cover letter implies that this suggestion is coming from me, which
> it definitely is not.  My preference, as I made clear from the very
> beginning, is to load ONLY the MOK DB CA keys onto the mok
> keyring.   (And even go one step farther, requiring the MOK DB CA
> key(s) to be identified on the boot command line.)

Ok, got it.  I guess I misunderstood and was thinking built-in should be 
referenced too for things going into the new mok keyring.

>> Currently, I’m not doing another pass.  I 
>> could add another pass, but it would not solve the issue with someone trying 
>> to load an intermediate CA along with a leaf cert.  This would require yet 
>> a third pass.  I wasn’t sure if this added complexity was necessary.  
>> 
>> Currently, any CA contained within the MOK db would now be trusted by the 
>> kernel.  Someone using a kernel with the secondary keyring enabled could 
>> load the intermediate and leaf certs themselves following boot.
> 
> Correct, as previously discussed, the other signed MOK DB keys may be
> loaded by userspace.   The only reason we're interested in any of the
> other MOK DB keys is prevent a regression.  As you previously pointed
> out all of the MOK DB keys are currently being loaded onto the platform
> keyring.  So leave the existing code, which loads the MOK DB keys onto
> the platform keyring, alone to prevent that regression.  It's already
> being controlled by a UEFI variable.

With this series, I do not believe a regression exists.  With a single pass, 
keys are either loaded into the mok or the platform keyring.  Since the mok
is linked to the secondary (or the built-in),  during kexec signature validation,
all keys are referenced. 

>> Taking 
>> this into account, if you’d like to see two passes, let me know and I’ll add 
>> that in v3.  If a second pass is done, do you really want these additional 
>> keys added to the secondary keyring or should they go into the mok keyring
>> instead?  I was under the impression the secondary should be empty until a
>> user adds their own keys into it. Thanks.
> 
> Again, my preference would be to load ONLY the MOK DB CA keys onto the
> mok keyring.

Ok, I’ll update the current code to just load CA keys into the mok in v3.  This would
simplify the new restrict_link_by_ca function. 

With that change, do you see any issues with how I’m doing the linking?  With the 
mok keyring linked to the secondary keyring, the platform keyring may only contain 
a subset of the keys it originally contained.  But, as I described above, I don’t believe
it will lead to a regression since all keys get referenced. Thanks.