linux-kernel - Re: [RFC PATCH] certs: Only allow certs signed by keys on the builtin keyring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 25 Oct 2023 08:48:42 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>,
        Denis Glazkov <d.glazkov@....ru>
Cc:     David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "David S . Miller" <davem@...emloft.net>, keyrings@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org
Subject: Re: [RFC PATCH] certs: Only allow certs signed by keys on the
 builtin keyring

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@...ux.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@...nel.org>

Thanks, Jarkko.   Applied.

-- 
thanks,

Mimi