linux-kernel - Re: [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <58e6e03b69b8fadfb854669086020c633837be88.camel@linux.ibm.com>
Date:   Thu, 12 Aug 2021 15:46:05 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>, keyrings@...r.kernel.org,
        linux-integrity@...r.kernel.org, dhowells@...hat.com,
        dwmw2@...radead.org, herbert@...dor.apana.org.au,
        davem@...emloft.net, jarkko@...nel.org, jmorris@...ei.org,
        serge@...lyn.com
Cc:     keescook@...omium.org, gregkh@...uxfoundation.org,
        torvalds@...ux-foundation.org, scott.branden@...adcom.com,
        weiyongjun1@...wei.com, nayna@...ux.ibm.com, ebiggers@...gle.com,
        ardb@...nel.org, nramas@...ux.microsoft.com, lszubowi@...hat.com,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        James.Bottomley@...senPartnership.com, pjones@...hat.com,
        glin@...e.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v3 10/14] KEYS: change link restriction for secondary to
 also trust mok

Hi Eric,

On Wed, 2021-08-11 at 22:18 -0400, Eric Snowberg wrote:
> With the introduction of the mok keyring, the end-user may choose to
> trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
> trust them, the .mok keyring will contain these keys.  If not, the mok
> keyring will always be empty.  Update the restriction check to allow the
> secondary trusted keyring to also trust mok keys.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@...cle.com>
> ---
> v3: Initial version
> ---
>  certs/system_keyring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index cb773e09ea67..8cc19a1ff051 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
>  	if (!restriction)
>  		panic("Can't allocate secondary trusted keyring restriction\n");
>  
> -	restriction->check = restrict_link_by_builtin_and_secondary_trusted;
> +	restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;
>  
>  	return restriction;
>  }

Not everyone needs to build a generic kernel, like the distros.  As
previously discussed, not everyone is willing to trust the new MOK
keyring nor the UEFI variable for enabling it.  For those environments,
they should be able to totally disable the MOK keyring.

Please define a Kconfig similar to "CONFIG_SECONDARY_TRUSTED_KEYRING"
for MOK.  The "restriction" would be based on the new Kconfig being
enabled.

thanks,

Mimi