From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Denis Glazkov" <d.glazkov@omp.ru>,
"Sergey Shtylyov" <s.shtylyov@omp.ru>
Cc: "dhowells@redhat.com" <dhowells@redhat.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] certs: Add option to disallow non-CA certificates in secondary trusted keying
Date: Tue, 12 Sep 2023 00:15:30 +0300 [thread overview]
Message-ID: <CVGEE9ODRR8I.1RIVO2MVE2UAX@suppilovahvero> (raw)
In-Reply-To: <20230908121330.4076-1-d.glazkov@omp.ru>
On Fri Sep 8, 2023 at 3:14 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 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>
s/keying/keyring/ (multiple)
Have you considered instead making mod_verify_sig() more robust?
Obviously this would mean making selection of keys in
verify_pkcs7_signature() more robust (see the documentation of
'trusted_keys').
The this would be also less niche feature to pick for distributors
if it was just concerning module loading, and have associated config
flag over there.
BR, Jarkko
next prev parent reply other threads:[~2023-09-12 3:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 11:32 [PATCH] certs: Add the ability to add only CA certificates to the secondary trusted keyring Denis Glazkov
2023-09-06 12:58 ` 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 [this message]
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=CVGEE9ODRR8I.1RIVO2MVE2UAX@suppilovahvero \
--to=jarkko@kernel.org \
--cc=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