Messages in this thread | | | From | Eric Snowberg <> | Subject | Re: [PATCH v3] certs: Add option to disallow non-CA certificates in secondary trusted keying | Date | Tue, 3 Oct 2023 19:04:09 +0000 |
| |
> On Oct 2, 2023, at 5:49 PM, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Mon Oct 2, 2023 at 1:46 PM EEST, Denis Glazkov wrote: >> The Linux kernel has an IMA (Integrity Measurement Architecture) >> subsystem to check the integrity of the file system based on digital >> signatures. IMA uses certificates in `.ima` keying to check integrity. >> >> Only certificates issued by one of the trusted CA (Certificate Authority) >> certificates can be added to the `.ima` keying. >> >> The Linux kernel now has a secondary trusted keying to which trusted >> certificates from user space can be added if you have superuser >> privileges. Previously, all trusted certificates were in the built-in >> trusted keying, which could not be modified from user space. >> Trusted certificates were placed in the built-in trusted keying at >> kernel compile time. >> >> The secondary trusted keying is designed so that any certificates that >> are signed by one of the trusted CA certificates in the built-in or >> secondary trusted keyring can be added to it. >> >> Let's imagine that we have the following certificate trust chain: >> >> ┌───────────────────────────┬─────────────────────┐ >> │ │ ┌───────┐ │ >> │ │ │ │ │ >> ┌────────────▼────────┐ ┌─────────────▼─────▼────┐ │ ┌─────┴─────┐ >> │.builtin_trusted_keys│◄───┤.secondary_trusted_keys ├──┘ │ .ima │ >> ├─────────────────────┤ ├────────────────────────┤ ├───────────┤ >> │ Root CA Cert │-----► Intermediate CA Cert │-----► IMA Cert │ >> └─────────────────────┘ └────────────────────────┘ └───────────┘ >> >> Issues Restricted by >> -------------► ──────────────► >> >> Since the IMA certificate is signed by a CA certificate from a secondary >> trusted keying, an attacker with superuser privileges will be able to >> add the IMA certificate to the secondary trusted keying. That is, the IMA >> certificate will become trusted. >> >> Since, with `CONFIG_MODULE_SIG` option enabled, modules can only be >> loaded into kernel space if they are signed with one of the trusted >> certificates, an attacker could sign untrusted kernel modules with >> the private key corresponding to the IMA certificate and successfully >> load the untrusted modules into kernel space. >> >> This patch was created not to solve only the problem of loading >> untrusted kernel modules, but to make it possible to use a secondary >> trusted keying only as a part of a chain of trust containing only >> CA certificates with no digital signature capability. This will >> help avoid similar problems when new features appear in the linux >> kernel that are similar to kernel modules in terms of their impact >> on system security, which will also use trusted certificates for >> signature verification. >> >> 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 (Certificate Authority) >> 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> >> --- >> v1 -> v2: >> - Rebase the patch from `linux-next` to the main `linux` repo master branch >> - Make the commit message more detailed >> - Move the variable declaration to the `if` block >> - Replace `#ifdef` with `IS_ENABLED` macro >> >> v2 -> v3: >> - Add the purpose and goal of the patch to the commit message >> --- >> certs/Kconfig | 9 +++++++++ >> certs/system_keyring.c | 16 ++++++++++++++++ >> 2 files changed, 25 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..ee14447374e7 100644 >> --- a/certs/system_keyring.c >> +++ b/certs/system_keyring.c >> @@ -99,6 +99,22 @@ int restrict_link_by_builtin_and_secondary_trusted( >> /* Allow the builtin keyring to be added to the secondary */ >> return 0; >> >> + if (IS_ENABLED(CONFIG_SECONDARY_TRUSTED_KEYRING_FOR_CA_CERTIFICATES_ONLY) && >> + dest_keyring == secondary_trusted_keys) { >> + const struct public_key *pub = payload->data[asym_crypto]; >> + >> + if (type != &key_type_asymmetric) >> + return -EOPNOTSUPP; >> + 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; >> + } >> + >> return restrict_link_by_signature(dest_keyring, type, payload, >> secondary_trusted_keys); >> } >> -- >> 2.34.1 > > I don't think this does any harm.
Right or wrong, there do seem to be Intermediate CA’s that have the digital signature usage set [1].
1. https://www.digicert.com/kb/digicert-root-certificates.htm#intermediates
> What do you think Mimi?
| |