[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160106134525.15633.73582.stgit@warthog.procyon.org.uk>
Date: Wed, 06 Jan 2016 13:45:25 +0000
From: David Howells <dhowells@...hat.com>
To: petkan@...-labs.com, jmorris@...ei.org
Cc: dhowells@...hat.com, linux-security-module@...r.kernel.org,
keyrings@...r.kernel.org, Mimi Zohar <zohar@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org
Subject: [PATCH] X.509: Partially revert patch to add validation against IMA
MOK keyring
Partially revert commit 41c89b64d7184a780f12f2cccdabe65cb2408893:
Author: Petko Manolov <petkan@...-labs.com>
Date: Wed Dec 2 17:47:55 2015 +0200
IMA: create machine owner and blacklist keyrings
The problem is that prep->trusted is a simple boolean and the additional
x509_validate_trust() call doesn't therefore distinguish levels of
trustedness, but is just OR'd with the result of validation against the
system trusted keyring.
However, setting the trusted flag means that this key may be added to *any*
trusted-only keyring - including the system trusted keyring.
Whilst I appreciate what the patch is trying to do, I don't think this is
quite the right solution.
Signed-off-by: David Howells <dhowells@...hat.com>
cc: Petko Manolov <petkan@...-labs.com>
cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>
cc: keyrings@...r.kernel.org
---
crypto/asymmetric_keys/x509_public_key.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_public_key.c b/crypto/asymmetric_keys/x509_public_key.c
index 9e9e5a6a9ed6..2a44b3752471 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -321,8 +321,6 @@ static int x509_key_preparse(struct key_preparsed_payload *prep)
goto error_free_cert;
} else if (!prep->trusted) {
ret = x509_validate_trust(cert, get_system_trusted_keyring());
- if (ret)
- ret = x509_validate_trust(cert, get_ima_mok_keyring());
if (!ret)
prep->trusted = 1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists