linux-kernel - Re: [PATCH v3 04/10] certs: Fix blacklist flag type confusion

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: <YAepvxOBcEU0paqA@kernel.org>
Date:   Wed, 20 Jan 2021 05:55:53 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Mickaël Salaün <mic@...ikod.net>
Cc:     David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "David S . Miller" <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        James Morris <jmorris@...ei.org>,
        Mickaël Salaün <mic@...ux.microsoft.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        "Serge E . Hallyn" <serge@...lyn.com>, keyrings@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>
Subject: Re: [PATCH v3 04/10] certs: Fix blacklist flag type confusion

On Thu, Jan 14, 2021 at 04:19:03PM +0100, Mickaël Salaün wrote:
> From: David Howells <dhowells@...hat.com>
> 
> KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(),
> as these only take KEY_ALLOC_* flags.  KEY_FLAG_KEEP has the same value as
> KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only key_create_or_update()
> uses it.  LSMs using the key_alloc hook don't check that flag.
> 
> KEY_FLAG_KEEP is then ignored but fortunately (again) the root user cannot
> write to the blacklist keyring, so it is not possible to remove a key/hash
> from it.
> 
> Fix this by adding a KEY_ALLOC_SET_KEEP flag that tells key_alloc() to set
> KEY_FLAG_KEEP on the new key.  blacklist_init() can then, correctly, pass
> this to keyring_alloc().

OK, so thing work by luck now, but given the new patches which allow
to append new keys they would break, right?

> We can also use this in ima_mok_init() rather than setting the flag
> manually.

What does ima_mok_init() do?
> Note that this doesn't fix an observable bug with the current
> implementation but it is required to allow addition of new hashes to the
> blacklist in the future without making it possible for them to be removed.
> 
> Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring")
> cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>

Nit: Cc

> Cc: David Woodhouse <dwmw2@...radead.org>
> Reported-by: Mickaël Salaün <mic@...ux.microsoft.com>
> Signed-off-by: David Howells <dhowells@...hat.com>
> [mic@...ux.microsoft.com: fix ima_mok_init()]
> Signed-off-by: Mickaël Salaün <mic@...ux.microsoft.com>
> ---
> 
> Changes since v2:
> * Cherry-pick rewritten v1 patch from
>   https://lore.kernel.org/lkml/2659836.1607940186@warthog.procyon.org.uk/
>   to rebase on v5.11-rc3 and fix ima_mok_init().
> ---
>  certs/blacklist.c                | 2 +-
>  include/linux/key.h              | 1 +
>  security/integrity/ima/ima_mok.c | 4 +---
>  security/keys/key.c              | 2 ++
>  4 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/certs/blacklist.c b/certs/blacklist.c
> index a888b934a1cd..029471947838 100644
> --- a/certs/blacklist.c
> +++ b/certs/blacklist.c
> @@ -162,7 +162,7 @@ static int __init blacklist_init(void)
>  			      KEY_USR_VIEW | KEY_USR_READ |
>  			      KEY_USR_SEARCH,
>  			      KEY_ALLOC_NOT_IN_QUOTA |
> -			      KEY_FLAG_KEEP,
> +			      KEY_ALLOC_SET_KEEP,
>  			      NULL, NULL);
>  	if (IS_ERR(blacklist_keyring))
>  		panic("Can't allocate system blacklist keyring\n");
> diff --git a/include/linux/key.h b/include/linux/key.h
> index 0f2e24f13c2b..eed3ce139a32 100644
> --- a/include/linux/key.h
> +++ b/include/linux/key.h
> @@ -289,6 +289,7 @@ extern struct key *key_alloc(struct key_type *type,
>  #define KEY_ALLOC_BUILT_IN		0x0004	/* Key is built into kernel */
>  #define KEY_ALLOC_BYPASS_RESTRICTION	0x0008	/* Override the check on restricted keyrings */
>  #define KEY_ALLOC_UID_KEYRING		0x0010	/* allocating a user or user session keyring */
> +#define KEY_ALLOC_SET_KEEP		0x0020	/* Set the KEEP flag on the key/keyring */
>  
>  extern void key_revoke(struct key *key);
>  extern void key_invalidate(struct key *key);
> diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
> index 36cadadbfba4..5594dd38ab04 100644
> --- a/security/integrity/ima/ima_mok.c
> +++ b/security/integrity/ima/ima_mok.c
> @@ -38,13 +38,11 @@ __init int ima_mok_init(void)
>  				(KEY_POS_ALL & ~KEY_POS_SETATTR) |
>  				KEY_USR_VIEW | KEY_USR_READ |
>  				KEY_USR_WRITE | KEY_USR_SEARCH,
> -				KEY_ALLOC_NOT_IN_QUOTA,
> +				KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP,
>  				restriction, NULL);
>  
>  	if (IS_ERR(ima_blacklist_keyring))
>  		panic("Can't allocate IMA blacklist keyring.");
> -
> -	set_bit(KEY_FLAG_KEEP, &ima_blacklist_keyring->flags);
>  	return 0;
>  }
>  device_initcall(ima_mok_init);
> diff --git a/security/keys/key.c b/security/keys/key.c
> index ebe752b137aa..c45afdd1dfbb 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -303,6 +303,8 @@ struct key *key_alloc(struct key_type *type, const char *desc,
>  		key->flags |= 1 << KEY_FLAG_BUILTIN;
>  	if (flags & KEY_ALLOC_UID_KEYRING)
>  		key->flags |= 1 << KEY_FLAG_UID_KEYRING;
> +	if (flags & KEY_ALLOC_SET_KEEP)
> +		key->flags |= 1 << KEY_FLAG_KEEP;
>  
>  #ifdef KEY_DEBUGGING
>  	key->magic = KEY_DEBUG_MAGIC;
> -- 
> 2.30.0
> 

Acked-by: Jarkko Sakkinen <jarkko@...nel.org>

/Jarkko