linux-kernel - [PATCH v1 6/9] 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: <20201120180426.922572-7-mic@digikod.net>
Date:   Fri, 20 Nov 2020 19:04:23 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        "David S . Miller" <davem@...emloft.net>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        James Morris <jmorris@...ei.org>,
        Jarkko Sakkinen <jarkko@...nel.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
Subject: [PATCH v1 6/9] certs: Fix blacklist flag type confusion

From: Mickaël Salaün <mic@...ux.microsoft.com>

KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() nor
key_alloc(), which only takes 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 such flag.

KEY_FLAG_KEEP is then ignored but fortunately (again) the root user
cannot write to the blacklist keyring, then it is not possible to remove
a key/hash from it.

Remove KEY_FLAG_KEEP from the call to keyring_alloc() and set the
keyring flags with it.

This should not fix a bug with the current implementation but it is
required for the next commit to allow to add new hashes to the blacklist
without the possibility to remove them.

Cc: David Howells <dhowells@...hat.com>
Cc: David Woodhouse <dwmw2@...radead.org>
Signed-off-by: Mickaël Salaün <mic@...ux.microsoft.com>
---
 certs/blacklist.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/certs/blacklist.c b/certs/blacklist.c
index 0d2c959e9422..d1e2f69d91c2 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -224,11 +224,11 @@ static int __init blacklist_init(void)
 			      (KEY_POS_ALL & ~KEY_POS_SETATTR) |
 			      KEY_USR_VIEW | KEY_USR_READ |
 			      KEY_USR_SEARCH,
-			      KEY_ALLOC_NOT_IN_QUOTA |
-			      KEY_FLAG_KEEP,
+			      KEY_ALLOC_NOT_IN_QUOTA,
 			      NULL, NULL);
 	if (IS_ERR(blacklist_keyring))
 		panic("Can't allocate system blacklist keyring\n");
+	set_bit(KEY_FLAG_KEEP, &blacklist_keyring->flags);
 
 	for (bl = blacklist_hashes; *bl; bl++)
 		if (mark_raw_hash_blacklisted(*bl) < 0)
-- 
2.29.2