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: <7df94da37c100c160436892a6996ba30e3fd6dc8.camel@linux.ibm.com>
Subject: Re: [PATCH v3 00/10] Add CA enforcement keyring restrictions
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Eric Snowberg <eric.snowberg@oracle.com>
Cc:     Jarkko Sakkinen <jarkko@kernel.org>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.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>,
        "paul@paul-moore.com" <paul@paul-moore.com>,
        "jmorris@namei.org" <jmorris@namei.org>,
        "serge@hallyn.com" <serge@hallyn.com>,
        "pvorel@suse.cz" <pvorel@suse.cz>,
        "noodles@fb.com" <noodles@fb.com>, "tiwai@suse.de" <tiwai@suse.de>,
        Kanth Ghatraju <kanth.ghatraju@oracle.com>,
        Konrad Wilk <konrad.wilk@oracle.com>,
        Elaine Palmer <erpalmer@linux.vnet.ibm.com>,
        Coiby Xu <coxu@redhat.com>,
        "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-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "linux-security-module@vger.kernel.org" 
        <linux-security-module@vger.kernel.org>
Date:   Thu, 15 Dec 2022 16:03:25 -0500
In-Reply-To: <17855993-519C-4DAC-B62F-9DB473CF249B@oracle.com>
References: <20221214003401.4086781-1-eric.snowberg@oracle.com>
         <b8e54d077da633132eb6da03ea536face095a425.camel@linux.ibm.com>
         <4CE6F17D-9D87-4024-9E1A-FDFE7C29D5FC@oracle.com>
         <1c51910a35a1d113256494827fd66ccc7473632e.camel@linux.ibm.com>
         <17855993-519C-4DAC-B62F-9DB473CF249B@oracle.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 2022-12-15 at 20:28 +0000, Eric Snowberg wrote:
> 
> > On Dec 15, 2022, at 12:58 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Thu, 2022-12-15 at 16:26 +0000, Eric Snowberg wrote:
> >> 
> >>> On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> On Tue, 2022-12-13 at 19:33 -0500, Eric Snowberg wrote:
> >>>> Prior to the introduction of the machine keyring, most distros simply 
> >>>> allowed all keys contained within the platform keyring to be used
> >>>> for both kernel and module verification.  This was done by an out of
> >>>> tree patch.  Some distros took it even further and loaded all these keys
> >>>> into the secondary trusted keyring.  This also allowed the system owner 
> >>>> to add their own key for IMA usage.
> >>>> 
> >>>> Each distro contains similar documentation on how to sign kernel modules
> >>>> and enroll the key into the MOK.  The process is fairly straightforward.
> >>>> With the introduction of the machine keyring, the process remains
> >>>> basically the same, without the need for any out of tree patches.
> >>>> 
> >>>> The machine keyring allowed distros to eliminate the out of tree patches
> >>>> for kernel module signing.  However, it falls short in allowing the end 
> >>>> user to add their own keys for IMA. Currently 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.  This would expand the current 
> >>>> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY 
> >>>> Kconfig states that keys may be added to the ima keyrings if the key is 
> >>>> validly signed by a CA cert in the system built-in or secondary trusted 
> >>>> keyring.  Currently there is not code that enforces the contents of a
> >>>> CA cert. Any key in the builtin or secondary keyring can be used. 
> >>>> 
> >>>> To allow IMA to be enabled with the machine keyring, this series introduces
> >>>> enforcement of key usage in the certificate. This series also applies
> >>>> this enforcement across all kernel keyrings.
> >>>> 
> >>>> The machine keyring shares  similarities with both the builtin and
> >>>> secondary keyrings.  Similar to the builtin, no keys may be added to the
> >>>> machine keyring following boot. The secondary keyring allows user
> >>>> provided keys to be added following boot; however, a previously enrolled
> >>>> kernel key must vouch for the key before it may be included. The system
> >>>> owner may include their own keys into the machine keyring prior to boot.
> >>>> If the end-user is not the system owner, they may not add their own keys
> >>>> to the machine keyring.  
> >>>> 
> >>>> The machine keyring is only populated when Secure Boot is enabled.  A
> >>>> system owner has the ability to control the entire Secure Boot keychain
> >>>> (PK, KEK, DB, and DBX).  The system owner can also turn Secure Boot off.
> >>>> With this control, they may use insert-sys-cert to include their own key 
> >>>> and re-sign their kernel and have it boot.  The system owner also has 
> >>>> control to include or exclude MOK keys. This series does not try to 
> >>>> interpret how a system owner has configured their machine.  If the system 
> >>>> owner has taken the steps to add their own MOK keys, they will be 
> >>>> included in the machine keyring and used for verification, exactly 
> >>>> the same way as keys contained in the builtin and secondary keyrings.
> >>>> Since the system owner has the ability to add keys before booting to
> >>>> either the machine or builtin keyrings, it is viewed as inconsequential 
> >>>> if the key originated from one or the other.
> >>>> 
> >>>> This series introduces two different ways to configure the machine keyring.
> >>>> By default, nothing changes and all MOK keys are loaded into it.  Whenever
> >>>> a CA cert is found within the machine, builtin, or secondary, a flag 
> >>>> indicating this is stored in the public key struct.  The other option is 
> >>>> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs 
> >>>> will be loaded into the machine keyring. All remaining MOK keys will be 
> >>>> loaded into the platform keyring.
> >>>> 
> >>>> A CA cert shall be defined as any X509 certificate that contains the 
> >>>> keyCertSign key usage and has the CA bit set to true.
> >>> 
> >>> Hi Eric,
> >>> 
> >>> Allowing CA certificates with the digitalSignature key usage flag
> >>> enabled defeats the purpose of the new Kconfig.  Please update the
> >>> above definition to exclude the digitalSignature key usage flag and
> >>> modify the code accordingly.
> >> 
> >> Within v2, the request was made to allow Intermediate CA certificates to be 
> >> loaded directly.  The Intermediate CA referenced was the one used by kernel.org.  
> >> This Intermediate CA contains both digitalSignature and keyCertSign.  If the code 
> >> is changed to exclude this certificate, now the root CA has to be loaded again.  Is that 
> >> the intent?
> > 
> > That definitely was not the intent.  Nor would it address the issue of
> > a particular intermediate CA certificate having both keyCertSign and
> > digitalSignature.
> 
> Sorry, I’m not following.  Why is it an issue that an intermediate CA certificate contains 
> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate
> CA cert like the one used on kernel.org?

I must be missing something.  Isn't the purpose of "keyUsage" to
minimize how a certificate may be used?   Why would we want the same
certificate to be used for both certificate signing and code signing?

thanks,

Mimi