Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <ed4e9e491c381ea201c1ac37501c6582fba6334d.camel@linux.ibm.com>
Subject: Re: [RFC PATCH] certs: Only allow certs signed by keys on the
 builtin keyring
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Jarkko Sakkinen <jarkko@kernel.org>,
        Denis Glazkov <d.glazkov@omp.ru>
Cc:     David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        "David S . Miller" <davem@davemloft.net>, keyrings@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org
Date:   Wed, 25 Oct 2023 08:48:42 -0400
In-Reply-To: <CWG7J7N7NE6L.3MHDW81QMPYRY@suppilovahvero>
References: <20231017122507.185896-1-zohar@linux.ibm.com>
         <CWG7J7N7NE6L.3MHDW81QMPYRY@suppilovahvero>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 2023-10-24 at 02:28 +0300, Jarkko Sakkinen wrote:
> On Tue Oct 17, 2023 at 3:25 PM EEST, Mimi Zohar wrote:
> > Originally the secondary trusted keyring provided a keyring to which extra
> > keys may be added, provided those keys were not blacklisted and were
> > vouched for by a key built into the kernel or already in the secondary
> > trusted keyring.
> >
> > On systems with the machine keyring configured, additional keys may also
> > be vouched for by a key on the machine keyring.
> >
> > Prevent loading additional certificates directly onto the secondary
> > keyring, vouched for by keys on the machine keyring, yet allow these
> > certificates to be loaded onto other trusted keyrings.
> >
> > Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
> > ---
> >  certs/Kconfig                     | 16 +++++++++++++++-
> >  crypto/asymmetric_keys/restrict.c |  4 ++++
> >  2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/certs/Kconfig b/certs/Kconfig
> > index 4a4dc8aab892..2e621963d260 100644
> > --- a/certs/Kconfig
> > +++ b/certs/Kconfig
> > @@ -88,7 +88,21 @@ config SECONDARY_TRUSTED_KEYRING
> >  	help
> >  	  If set, provide a keyring to which extra keys may be added, provided
> >  	  those keys are not blacklisted and are vouched for by a key built
> > -	  into the kernel or already in the secondary trusted keyring.
> > +	  into the kernel, machine keyring (if configured), or already in the
> > +	  secondary trusted keyring.
> > +
> > +config SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN
> > +	bool "Only allow additional certs signed by keys on the builtin trusted keyring"
> > +	depends on SECONDARY_TRUSTED_KEYRING
> > +	help
> > +	  If set, only certificates signed by keys on the builtin trusted
> > +	  keyring may be loaded onto the secondary trusted keyring.
> > +
> > +	  Note: The machine keyring, if configured, will be linked to the
> > +	  secondary keyring.  When enabling this option, it is recommended
> > +	  to also configure INTEGRITY_CA_MACHINE_KEYRING_MAX to prevent
> > +	  linking code signing keys with imputed trust to the secondary
> > +	  trusted keyring.
> >  
> >  config SECONDARY_TRUSTED_KEYRING_FOR_CA_CERTIFICATES_ONLY
> >  	bool "Allow only CA certificates to be added to the secondary trusted keyring"
> > diff --git a/crypto/asymmetric_keys/restrict.c b/crypto/asymmetric_keys/restrict.c
> > index 6b69ea40da23..afcd4d101ac5 100644
> > --- a/crypto/asymmetric_keys/restrict.c
> > +++ b/crypto/asymmetric_keys/restrict.c
> > @@ -102,6 +102,10 @@ int restrict_link_by_signature(struct key *dest_keyring,
> >  
> >  	if (use_builtin_keys && !test_bit(KEY_FLAG_BUILTIN, &key->flags))
> >  		ret = -ENOKEY;
> > +	else if (IS_BUILTIN(CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN) &&
> > +		 !strcmp(dest_keyring->description, ".secondary_trusted_keys") &&
> > +		 !test_bit(KEY_FLAG_BUILTIN, &key->flags))
> > +		ret = -ENOKEY;
> >  	else
> >  		ret = verify_signature(key, sig);
> >  	key_put(key);
> 
> Plese pick this to your tree.
> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

Thanks, Jarkko.   Applied.

-- 
thanks,

Mimi