[PATCH] certs: Add the ability to add only CA certificates to the secondary trusted keyring

From: Denis Glazkov
Date: Wed Sep 06 2023 - 07:33:17 EST


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@xxxxxx>
---
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