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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <2BBC3A71-6E0D-47A2-842A-11C279A5DC56@oracle.com>
Date:   Tue, 3 Aug 2021 13:52:49 -0600
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
Cc:     keyrings@...r.kernel.org, linux-integrity@...r.kernel.org,
        dhowells@...hat.com, dwmw2@...radead.org,
        herbert@...dor.apana.org.au, davem@...emloft.net,
        jarkko@...nel.org, jmorris@...ei.org, serge@...lyn.com,
        keescook@...omium.org, gregkh@...uxfoundation.org,
        torvalds@...ux-foundation.org, scott.branden@...adcom.com,
        weiyongjun1@...wei.com, nayna@...ux.ibm.com, ebiggers@...gle.com,
        ardb@...nel.org, nramas@...ux.microsoft.com, lszubowi@...hat.com,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        James.Bottomley@...senPartnership.com, pjones@...hat.com,
        glin@...e.com, "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>
Subject: Re: [PATCH RFC v2 00/12] Enroll kernel keys thru MOK

> On Aug 3, 2021, at 11:01 AM, Mimi Zohar <zohar@...ux.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.  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.  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.