From: Eric Snowberg <eric.snowberg@oracle.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
dhowells@redhat.com, dwmw2@infradead.org,
herbert@gondor.apana.org.au, davem@davemloft.net,
jarkko@kernel.org, jmorris@namei.org, serge@hallyn.com,
keescook@chromium.org, gregkh@linuxfoundation.org,
torvalds@linux-foundation.org, scott.branden@broadcom.com,
weiyongjun1@huawei.com, nayna@linux.ibm.com, ebiggers@google.com,
ardb@kernel.org, nramas@linux.microsoft.com, lszubowi@redhat.com,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-security-module@vger.kernel.org,
James.Bottomley@HansenPartnership.com, pjones@redhat.com,
glin@suse.com, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [PATCH RFC v2 00/12] Enroll kernel keys thru MOK
Date: Tue, 3 Aug 2021 13:52:49 -0600 [thread overview]
Message-ID: <2BBC3A71-6E0D-47A2-842A-11C279A5DC56@oracle.com> (raw)
In-Reply-To: <820cd72cd77c4716bff2bf344c64d7bcb59fc4d3.camel@linux.ibm.com>
> On Aug 3, 2021, at 11:01 AM, Mimi Zohar <zohar@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. 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.
next prev parent reply other threads:[~2021-08-03 19:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-26 17:13 [PATCH RFC v2 00/12] Enroll kernel keys thru MOK Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 01/12] integrity: Introduce a Linux keyring for the Machine Owner Key (MOK) Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 02/12] KEYS: CA link restriction Eric Snowberg
2021-08-05 14:00 ` Mimi Zohar
2021-07-26 17:13 ` [PATCH RFC v2 03/12] integrity: Trust MOK keys if MokListTrustedRT found Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 04/12] integrity: add add_to_mok_keyring Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 05/12] integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_system_trusted_or_ca Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 06/12] integrity: accessor function to get trust_moklist Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 07/12] integrity: add new keyring handler for mok keys Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 08/12] integrity: Suppress error message for keys added to the mok keyring Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 09/12] KEYS: add a reference to " Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 10/12] KEYS: link system_trusted_keys to mok_trusted_keys Eric Snowberg
2021-08-05 13:58 ` Mimi Zohar
2021-08-06 1:29 ` Eric Snowberg
2021-08-06 3:19 ` Mimi Zohar
2021-08-06 15:00 ` Eric Snowberg
2021-08-06 15:18 ` Mimi Zohar
2021-08-06 21:20 ` Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 11/12] integrity: Do not allow mok keyring updates following init Eric Snowberg
2021-07-26 17:13 ` [PATCH RFC v2 12/12] integrity: store reference to mok keyring Eric Snowberg
2021-08-03 17:01 ` [PATCH RFC v2 00/12] Enroll kernel keys thru MOK Mimi Zohar
2021-08-03 19:52 ` Eric Snowberg [this message]
2021-08-04 1:14 ` Mimi Zohar
2021-08-04 2:56 ` Eric Snowberg
2021-08-05 13:58 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2BBC3A71-6E0D-47A2-842A-11C279A5DC56@oracle.com \
--to=eric.snowberg@oracle.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=ardb@kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@google.com \
--cc=glin@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lszubowi@redhat.com \
--cc=nayna@linux.ibm.com \
--cc=nramas@linux.microsoft.com \
--cc=pjones@redhat.com \
--cc=scott.branden@broadcom.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
--cc=weiyongjun1@huawei.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).