Message-ID: <21E52C3E-0778-4908-AF44-F65D57BEC4E0@oracle.com>
Date:   Thu, 15 Dec 2022 21:45: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 2:03 PM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 
> On Thu, 2022-12-15 at 20:28 +0000, Eric Snowberg wrote:
>> 
>>> 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?
> 
> 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?

Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set.  
Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature 
set.  Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be 
challenging and will severely limit usage.

Powered by blists - more mailing lists