Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6bfe3fe98eb7c11520264503fd10da478d6a3fd3.camel@linux.ibm.com>
Subject: Re: [PATCH 0/7] Add CA enforcement keyring restrictions
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Eric Snowberg <eric.snowberg@oracle.com>, dhowells@redhat.com,
        dwmw2@infradead.org, jarkko@kernel.org,
        linux-integrity@vger.kernel.org
Cc:     herbert@gondor.apana.org.au, davem@davemloft.net,
        dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
        roberto.sassu@huawei.com, nramas@linux.microsoft.com,
        pvorel@suse.cz, tiwai@suse.de, keyrings@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        linux-security-module@vger.kernel.org
Date:   Wed, 06 Apr 2022 16:45:58 -0400
In-Reply-To: <20220406015337.4000739-1-eric.snowberg@oracle.com>
References: <20220406015337.4000739-1-eric.snowberg@oracle.com>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Eric,

On Tue, 2022-04-05 at 21:53 -0400, Eric Snowberg wrote:
> A key added to the ima keyring must be signed by a key contained within 
> either the builtin trusted or secondary trusted keyrings. Currently, there are 
> CA restrictions described in IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY,
> but these restrictions are not enforced within code. Therefore, keys within 
> either the builtin or secondary may not be a CA and could be used to
> vouch for an ima key.
> 
> The machine keyring can not be used as another trust anchor for adding keys 
> to the ima keyring, since CA enforcement does not currently exist [1]. This 
> would expand the current integrity gap.
> 
> Introduce a new root of trust key flag to close this integrity gap for
> all keyrings.  The first key type to use this is X.509.  When a X.509 
> certificate is self signed, contains kernCertSign Key Usage and contains 
> the CA bit, the new flag is set.  Introduce new keyring restrictions 
> that not only validates a key is signed by a key contained within the 
> keyring, but also validates the key has the new root of trust key flag 
> set.  Use this new restriction for keys added to the ima keyring.  Now 
> that we have CA enforcement, allow the machine keyring to be used as another 
> trust anchor for the ima keyring.
> 
> To recap, all keys that previously loaded into the builtin, secondary or
> machine keyring will still load after applying this series.  Keys
> contained within these keyrings may carry the root of trust flag. The
> ima keyring will use the new root of trust restriction to validate
> CA enforcement. Other keyrings that require a root of trust could also 
> use this in the future.

Your initial patch set indicated that you were addressing Linus'
request to allow end-users the ability "to add their own keys and sign
modules they trust".  However, from the design of the previous patch
set and now this one, everything indicates a lot more is going on than
just allowing end-users to add their own keys.  There would be no
reason for loading all the MOK keys, rather than just the CA keys, onto
the "machine" keyring.  Please provide the motivation for this design.

Please note that Patch 6/7 permits intermediary CA keys, without any
mention of it in the cover letter.  Please include this in the
motivation for this design.

thanks,

Mimi