From: Mimi Zohar <zohar@linux.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: David Howells <dhowells@redhat.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
Jarkko Sakkinen <jarkko@kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
"pvorel@suse.cz" <pvorel@suse.cz>,
"tiwai@suse.de" <tiwai@suse.de>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 4/7] KEYS: Introduce a builtin root of trust key flag
Date: Mon, 11 Apr 2022 11:30:48 -0400 [thread overview]
Message-ID: <6798c67d748ecdc92455a8be8c63fb55e243368a.camel@linux.ibm.com> (raw)
In-Reply-To: <BFA04505-F4BC-4CF8-B813-EE81DBD90E09@oracle.com>
On Fri, 2022-04-08 at 21:59 +0000, Eric Snowberg wrote:
> > On Apr 8, 2022, at 12:49 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > On Fri, 2022-04-08 at 17:34 +0000, Eric Snowberg wrote:
> >>
> >>> On Apr 8, 2022, at 10:55 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>
> >>> On Fri, 2022-04-08 at 15:27 +0000, Eric Snowberg wrote:
> >>>>
> >>>>> On Apr 8, 2022, at 8:40 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>
> >>>>> On Tue, 2022-04-05 at 21:53 -0400, Eric Snowberg wrote:
> >>>>>>
> >>>>>> The first type of key to use this is X.509. When a X.509 certificate
> >>>>>> is self signed, has the kernCertSign Key Usage set and contains the
> >>>>>> CA bit set this new flag is set.
> >>>>>>
> >>>>>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> >>>>>>
> >>>>>> diff --git a/include/linux/key.h b/include/linux/key.h
> >>>>>> index 7febc4881363..97f6a1f86a27 100644
> >>>>>> --- a/include/linux/key.h
> >>>>>> +++ b/include/linux/key.h
> >>>>>> @@ -230,6 +230,7 @@ struct key {
> >>>>>> #define KEY_FLAG_ROOT_CAN_INVAL 7 /* set if key can be invalidated by root without permission */
> >>>>>> #define KEY_FLAG_KEEP 8 /* set if key should not be removed */
> >>>>>> #define KEY_FLAG_UID_KEYRING 9 /* set if key is a user or user session keyring */
> >>>>>> +#define KEY_FLAG_BUILTIN_ROT 10 /* set if key is a builtin Root of Trust key */
> >>>>>>
> >>>>>> /* the key type and key description string
> >>>>>> * - the desc is used to match a key against search criteria
> >>>>>> @@ -290,6 +291,7 @@ extern struct key *key_alloc(struct key_type *type,
> >>>>>> #define KEY_ALLOC_BYPASS_RESTRICTION 0x0008 /* Override the check on restricted keyrings */
> >>>>>> #define KEY_ALLOC_UID_KEYRING 0x0010 /* allocating a user or user session keyring */
> >>>>>> #define KEY_ALLOC_SET_KEEP 0x0020 /* Set the KEEP flag on the key/keyring */
> >>>>>> +#define KEY_ALLOC_BUILT_IN_ROT 0x0040 /* Add builtin root of trust key */
> >>>>>
> >>>>> Since the concept of root of trust is not generic, but limited to
> >>>>> specific keyrings, the root CA certificate signing keys on the
> >>>>> "machine" keyring need to be identified. Similar to the
> >>>>> KEY_ALLOC_BUILT_IN/KEY_FLAG_BUILTIN, new flags
> >>>>> KEY_ALLOC_MACHINE/KEY_FLAG_MACHINE should be defined instead.
> >>>>
> >>>> I’m open to renaming these, however this name change seems confusing to me.
> >>>> This flag gets set when the X.509 certificate contains the three CA requirements
> >>>> identified above. The remaining keys in the machine keyring can be used for
> >>>> anything else.
> >>>
> >>> Renaming the flag to KEY_ALLOC_MACHINE/KEY_FLAG_MACHINE differentiates
> >>> between the "builtin" keys from the "machine" keys. The trust models
> >>> are very different.
> >>
> >> Isn’t the trust model the same for machine and secondary keys? Both are supplied by
> >> the end-user. That is why I’m confused by naming something _MACHINE when it applies
> >> to more than one keyring.
> >
> > True both are supplied by the end-user, but the trust models are
> > different.
>
> I think I need more information here, I’m not seeing how they are different trust
> models.
In order to discuss trust models, we need to understand the different
use-cases that are being discussed here without ever having been
explicitly stated. Here are a few:
- Allow users to sign their own kernel modules.
- Allow users to selectively authorize 3rd party certificates to verify
kernel modules.
- From an IMA perspective, allow users to sign files within their own
software packages.
Each of the above use-cases needs to be independently configurable,
thoroughly explained, and enforced.
thanks,
Mimi
>
> > In one case the certificates are coming indirectly from
> > firmware,
next prev parent reply other threads:[~2022-04-11 15:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-06 1:53 [PATCH 0/7] Add CA enforcement keyring restrictions Eric Snowberg
2022-04-06 1:53 ` [PATCH 1/7] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2022-04-06 1:53 ` [PATCH 2/7] KEYS: X.509: Parse Basic Constraints for CA Eric Snowberg
2022-04-08 14:39 ` Mimi Zohar
2022-04-08 15:31 ` Eric Snowberg
2022-04-06 1:53 ` [PATCH 3/7] KEYS: X.509: Parse Key Usage Eric Snowberg
2022-04-08 14:39 ` Mimi Zohar
2022-04-06 1:53 ` [PATCH 4/7] KEYS: Introduce a builtin root of trust key flag Eric Snowberg
2022-04-08 14:40 ` Mimi Zohar
2022-04-08 15:27 ` Eric Snowberg
2022-04-08 16:55 ` Mimi Zohar
2022-04-08 17:34 ` Eric Snowberg
2022-04-08 18:49 ` Mimi Zohar
2022-04-08 21:59 ` Eric Snowberg
2022-04-11 15:30 ` Mimi Zohar [this message]
2022-04-14 16:36 ` Eric Snowberg
2022-04-14 18:09 ` Mimi Zohar
2022-04-14 21:59 ` Eric Snowberg
2022-04-15 16:14 ` Mimi Zohar
2022-04-06 1:53 ` [PATCH 5/7] KEYS: Introduce sig restriction that validates root of trust Eric Snowberg
2022-04-06 19:55 ` kernel test robot
2022-04-06 1:53 ` [PATCH 6/7] KEYS: X.509: Flag Intermediate CA certs as built in Eric Snowberg
2022-04-07 1:04 ` kernel test robot
2022-04-06 1:53 ` [PATCH 7/7] integrity: Use root of trust signature restriction Eric Snowberg
2022-04-06 20:45 ` [PATCH 0/7] Add CA enforcement keyring restrictions Mimi Zohar
2022-04-06 22:53 ` Eric Snowberg
2022-04-08 14:41 ` Mimi Zohar
2022-11-04 13:20 ` Coiby Xu
2022-11-04 21:06 ` Eric Snowberg
2022-11-09 1:24 ` Elaine Palmer
2022-11-09 14:25 ` Eric Snowberg
2022-11-09 14:58 ` Elaine Palmer
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=6798c67d748ecdc92455a8be8c63fb55e243368a.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--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=nramas@linux.microsoft.com \
--cc=pvorel@suse.cz \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=tiwai@suse.de \
/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).