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

Hi Eric,

On Tue, 2021-08-03 at 13:52 -0600, Eric Snowberg wrote:

quoted

On Aug 3, 2021, at 11:01 AM, Mimi Zohar [off-list ref] wrote:

On Mon, 2021-07-26 at 13:13 -0400, Eric Snowberg wrote:

quoted

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.)

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.

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.

If YOU decide you want to load the signed keys stored in MOK DB, be my
guest.  However, they should be loaded onto the secondary keyring and a
new restriction defined, similar to
"restrict_link_by_builtin_and_secondary_trusted", which includes mok as
well.

thanks,

Mimi