Message-ID: <B67D99B1-1DF9-4146-9147-08B2C4A72FEA@oracle.com>
Date:   Thu, 14 Apr 2022 16:36:05 +0000
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
CC:     David Howells <dhowells@...hat.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "dmitry.kasatkin@...il.com" <dmitry.kasatkin@...il.com>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        "pvorel@...e.cz" <pvorel@...e.cz>, "tiwai@...e.de" <tiwai@...e.de>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 4/7] KEYS: Introduce a builtin root of trust key flag



> On Apr 11, 2022, at 9:30 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 
> On Fri, 2022-04-08 at 21:59 +0000, Eric Snowberg wrote:
>>> On Apr 8, 2022, at 12:49 PM, Mimi Zohar <zohar@...ux.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@...ux.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@...ux.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@...cle.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.

I’m still confused by the request here.  All these use cases can be done 
today with insert-sys-cert.  Take the, " allow user to sign their own kernel 
modules" use case.  Using insert-sys-cert, any type of key can be added 
to the builtin trusted keyring, it doesn’t need to be self signed, there are 
no restrictions on fields in the certificate.  The same approach can be used 
to allow users to ima sign their own files. Any key can be added, it doesn’t 
need to be a CA. The same goes for 3rd party signed modules.

This series doesn’t enable keys to be used for any new purpose than what 
can be done today.  In fact it limits how system keys may be used. It does 
this by adding a new restriction.  The new restriction enforces the CA 
requirements ima expects. This restriction is enforced on all keyrings ima 
references (builtin or secondary).  Since the machine keyring is linked to 
the secondary, it may now be used, since the CA restriction ima expects will 
be enforced.

Powered by blists - more mailing lists