Message-ID: <17855993-519C-4DAC-B62F-9DB473CF249B@oracle.com>
Date:   Thu, 15 Dec 2022 20:28:37 +0000
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
CC:     Jarkko Sakkinen <jarkko@...nel.org>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.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>,
        "paul@...l-moore.com" <paul@...l-moore.com>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "pvorel@...e.cz" <pvorel@...e.cz>,
        "noodles@...com" <noodles@...com>, "tiwai@...e.de" <tiwai@...e.de>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Konrad Wilk <konrad.wilk@...cle.com>,
        Elaine Palmer <erpalmer@...ux.vnet.ibm.com>,
        Coiby Xu <coxu@...hat.com>,
        "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-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v3 00/10] Add CA enforcement keyring restrictions



> On Dec 15, 2022, at 12:58 PM, Mimi Zohar <zohar@...ux.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@...ux.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?

Powered by blists - more mailing lists