From: Denis Glazkov <d.glazkov@omp.ru>
To: unlisted-recipients:; (no To-header on input)
Cc: Sergey Shtylyov <s.shtylyov@omp.ru>,
Denis Glazkov <d.glazkov@omp.ru>,
David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [PATCH] certs: Add the ability to add only CA certificates to the secondary trusted keyring
Date: Wed, 6 Sep 2023 11:32:21 +0000 [thread overview]
Message-ID: <20230906113211.82362-1-d.glazkov@omp.ru> (raw)
When building a chain of trust for IMA certificates issued from
intermediate certificates using a secondary trusted keying, there
is no way to restrict the addition of IMA certificates to trusted
certificates, since any certificate signed by an built-in or
secondary trusted certificate can be added to the secondary
trusted keying.
With root privileges, an attacker can load a certificate intended
for IMA into the trusted certificates and sign the kernel modules
with the corresponding private key. This allows an attacker to
load untrusted modules into kernel space.
This patch adds the configuration that once enabled, only
certificates that meet the following requirements can be added
to the secondary trusted keying:
1. The certificate is a CA.
2. The certificate must be used for verifying a CA's signatures.
3. The certificate must not be used for digital signatures.
Signed-off-by: Denis Glazkov <d.glazkov@omp.ru>
---
certs/Kconfig | 9 +++++++++
certs/system_keyring.c | 21 +++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/certs/Kconfig b/certs/Kconfig
index 1f109b070877..4a4dc8aab892 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -90,6 +90,15 @@ config SECONDARY_TRUSTED_KEYRING
those keys are not blacklisted and are vouched for by a key built
into the kernel or already in 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"
+ depends on SECONDARY_TRUSTED_KEYRING
+ help
+ If set, only CA certificates can be added to the secondary trusted keyring.
+ An acceptable CA certificate must include the `keyCertSign` value in
+ the `keyUsage` field. CA certificates that include the `digitalSignature`
+ value in the `keyUsage` field will not be accepted.
+
config SYSTEM_BLACKLIST_KEYRING
bool "Provide system-wide ring of blacklisted keys"
depends on KEYS
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 9de610bf1f4b..8d45c19ba92e 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -90,6 +90,10 @@ int restrict_link_by_builtin_and_secondary_trusted(
const union key_payload *payload,
struct key *restrict_key)
{
+#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING_FOR_CA_CERTIFICATES_ONLY
+ struct public_key *pub;
+#endif
+
/* If we have a secondary trusted keyring, then that contains a link
* through to the builtin keyring and the search will follow that link.
*/
@@ -99,6 +103,23 @@ int restrict_link_by_builtin_and_secondary_trusted(
/* Allow the builtin keyring to be added to the secondary */
return 0;
+#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING_FOR_CA_CERTIFICATES_ONLY
+ if (dest_keyring == secondary_trusted_keys) {
+ if (type != &key_type_asymmetric)
+ return -EOPNOTSUPP;
+
+ pub = payload->data[asym_crypto];
+ if (!pub)
+ return -ENOPKG;
+ if (!test_bit(KEY_EFLAG_CA, &pub->key_eflags))
+ return -EPERM;
+ if (!test_bit(KEY_EFLAG_KEYCERTSIGN, &pub->key_eflags))
+ return -EPERM;
+ if (test_bit(KEY_EFLAG_DIGITALSIG, &pub->key_eflags))
+ return -EPERM;
+ }
+#endif
+
return restrict_link_by_signature(dest_keyring, type, payload,
secondary_trusted_keys);
}
--
2.34.1
next reply other threads:[~2023-09-06 11:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 11:32 Denis Glazkov [this message]
2023-09-06 12:58 ` [PATCH] certs: Add the ability to add only CA certificates to the secondary trusted keyring Sergey Shtylyov
2023-09-08 12:14 ` [PATCH v2] certs: Add option to disallow non-CA certificates in secondary trusted keying Denis Glazkov
2023-09-11 21:15 ` Jarkko Sakkinen
2023-09-15 17:50 ` Denis Glazkov
2023-09-25 16:54 ` Jarkko Sakkinen
2023-10-02 10:46 ` [PATCH v3] " Denis Glazkov
2023-10-02 23:49 ` Jarkko Sakkinen
2023-10-03 19:04 ` Eric Snowberg
2023-10-05 21:33 ` Denis Glazkov
2023-10-09 14:10 ` Mimi Zohar
2023-10-17 12:43 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230906113211.82362-1-d.glazkov@omp.ru \
--to=d.glazkov@omp.ru \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=s.shtylyov@omp.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).