Message-ID: <D598759A-48FD-46E2-979C-3022A5920C0F@oracle.com>
Date:   Wed, 8 Feb 2023 23:26:26 +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>,
        "tadeusz.struk@...el.com" <tadeusz.struk@...el.com>,
        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>,
        "Lee, Chun-Yi" <jlee@...e.com>
Subject: Re: [PATCH v4 0/6] Add CA enforcement keyring restrictions



> On Feb 8, 2023, at 5:38 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> 
> [CC'ing: Lee, Chun-Yi]
> 
> On Mon, 2023-02-06 at 21:59 -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.
>> 
>> This series introduces a way to do CA enforement with the machine
>> keyring. It introduces three different ways to configure the machine
>> keyring. A new menu option is added to control the type of keys that may
>> be added to it.  The options include none, min, and max restrictions. The
>> default is CONFIG_INTEGRITY_CA_MACHINE_KEYRING_NONE. This allows all MOK
>> keys into the machine keyring.  When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MIN
>> is selected, the X.509 CA bit must be true.  Also, the key usage must
>> contain keyCertSign, any other usage field may also be set. When 
>> CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the X.509 CA bit
>> must be true.  Also, the key usage must contain keyCertSign and the
>> digitialSignature usage may not be set. If a key doesn't pass the CA
>> restriction check, instead of going into the machine keyring, it is
>> added to the platform keyring. With the ability to configure the machine
>> keyring with CA restrictions, code that prevented the machine keyring
>> from being enabled with IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
>> has been removed.
>> 
>> Changelog:
>> v4:
>> - Removed all code that validated the certificate chain back to the root
>>  CA. Now the only restriction is what is initially placed in the
>>  machine keyring.
>> - Check and store if the X.509 usage contains digitalSignature
>> - New Kconfig menu item with none, min and max CA restriction on the 
>>  machine keyring
> 
> Thank you, Eric.
> 
> For complete separation of certificate usage, at least in the "max" CA
> restriction case, the next step would be to limit certificates being
> loaded onto the IMA keyring to those with key usage of
> "digitalSignature".
> 
> Perhaps also require a "codeSigning" extendedKeyUsage, though that
> might break existing usages.  The "codeSigning" checking could
> piggyback on Joey's proposed "Check codeSigning extended key usage
> extension" patch set.
> 
> What do you think?  Do you have any concerns with limiting the type of
> certificate being loaded onto the IMA keyring to those with
> "digitalSignature"?

In the MAX setting I would not have a concern.  Instead of restrict_link_to_ima 
being a macro, a new restriction similar to restrict_link_by_ca could be created.  
The new restriction would simply verify digitialSignature is set and the key can be 
vouched for by either the built-in or secondary keyrings. Joey’s work to parse 
the extended key usage extension could also be included in this restriction.

I’m assuming this would be follow on work?

Powered by blists - more mailing lists