From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mimi Zohar" <zohar@linux.ibm.com>,
"Eric Snowberg" <eric.snowberg@oracle.com>, <dhowells@redhat.com>,
<dwmw2@infradead.org>
Cc: <mic@linux.microsoft.com>, <kanth.ghatraju@oracle.com>,
<konrad.wilk@oracle.com>, <linux-integrity@vger.kernel.org>,
<keyrings@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring
Date: Tue, 12 Sep 2023 01:04:47 +0300 [thread overview]
Message-ID: <CVGFG0625KNL.3B8Z118U3IGBY@suppilovahvero> (raw)
In-Reply-To: <097a0413b27ed9792dc598ff184730bcf6ae8fcf.camel@linux.ibm.com>
On Mon Sep 11, 2023 at 4:29 PM EEST, Mimi Zohar wrote:
> Hi Eric,
>
> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
> > Currently root can dynamically update the blacklist keyring if the hash
> > being added is signed and vouched for by the builtin trusted keyring.
> > Currently keys in the secondary trusted keyring can not be used.
> >
> > Keys within the secondary trusted keyring carry the same capabilities as
> > the builtin trusted keyring. Relax the current restriction for updating
> > the .blacklist keyring and allow the secondary to also be referenced as
> > a trust source. Since the machine keyring is linked to the secondary
> > trusted keyring, any key within it may also be used.
> >
> > An example use case for this is IMA appraisal. Now that IMA both
> > references the blacklist keyring and allows the machine owner to add
> > custom IMA CA certs via the machine keyring, this adds the additional
> > capability for the machine owner to also do revocations on a running
> > system.
> >
> > IMA appraisal usage example to add a revocation for /usr/foo:
> >
> > sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt
> >
> > openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
> > -signer machine-certificate.pem -noattr -binary -outform DER \
> > -out hash.p7s
> >
> > keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s
> >
> > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>
> The secondary keyring may include both CA and code signing keys. With
> this change any key loaded onto the secondary keyring may blacklist a
> hash. Wouldn't it make more sense to limit blacklisting
> certificates/hashes to at least CA keys?
I think a bigger issue is that if a kernel is updated with this patch
it will change the behavior. It is nothing to do whether the "old" or
"new" is better but more like kind of backwards compatibility issue.
BR, Jarkko
next prev parent reply other threads:[~2023-09-12 2:59 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 21:34 [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Eric Snowberg
2023-09-11 13:29 ` Mimi Zohar
2023-09-11 16:51 ` Mickaël Salaün
2023-09-11 22:17 ` Eric Snowberg
2023-09-11 23:08 ` Mimi Zohar
2023-09-12 2:00 ` Eric Snowberg
2023-09-12 11:54 ` Mimi Zohar
2023-09-12 17:11 ` Eric Snowberg
2023-09-12 22:47 ` Mimi Zohar
2023-09-13 2:40 ` Eric Snowberg
2023-09-13 10:21 ` Mickaël Salaün
2023-09-13 22:29 ` Eric Snowberg
2023-09-14 8:34 ` Mickaël Salaün
2023-10-05 10:32 ` RFC: New LSM to control usage of x509 certificates Mickaël Salaün
2023-10-05 14:05 ` Paul Moore
2023-10-17 13:39 ` Mimi Zohar
2023-10-17 15:45 ` Paul Moore
2023-10-17 17:08 ` Mimi Zohar
2023-10-17 17:29 ` Paul Moore
2023-10-17 17:58 ` Mimi Zohar
2023-10-17 18:51 ` Paul Moore
2023-10-17 19:34 ` Eric Snowberg
2023-10-18 14:14 ` Mickaël Salaün
2023-10-18 23:12 ` Eric Snowberg
2023-10-19 9:12 ` Mickaël Salaün
2023-10-19 23:08 ` Eric Snowberg
2023-10-20 15:05 ` Mickaël Salaün
2023-10-20 15:26 ` Roberto Sassu
2023-10-20 15:53 ` Eric Snowberg
2023-09-11 22:04 ` Jarkko Sakkinen [this message]
2023-09-11 22:23 ` [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring Eric Snowberg
2023-09-11 22:01 ` Jarkko Sakkinen
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=CVGFG0625KNL.3B8Z118U3IGBY@suppilovahvero \
--to=jarkko@kernel.org \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eric.snowberg@oracle.com \
--cc=kanth.ghatraju@oracle.com \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mic@linux.microsoft.com \
--cc=zohar@linux.ibm.com \
/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