From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: "open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>,
"David Howells" <dhowells@redhat.com>,
"David Woodhouse" <dwmw2@infradead.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Dmitry Kasatkin" <dmitry.kasatkin@gmail.com>,
"Mickaël Salaün" <mic@digikod.net>,
"casey@schaufler-ca.com" <casey@schaufler-ca.com>,
"Stefan Berger" <stefanb@linux.ibm.com>,
"ebiggers@kernel.org" <ebiggers@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"open list" <linux-kernel@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>
Subject: Re: [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)
Date: Fri, 18 Oct 2024 00:58:05 +0300 [thread overview]
Message-ID: <2e696bea1657b6c1a9309be7aa0e217fec47b750.camel@kernel.org> (raw)
In-Reply-To: <46017A8E-88EB-4B8D-9FB2-643F9A5BF7F0@oracle.com>
On Thu, 2024-10-17 at 21:42 +0000, Eric Snowberg wrote:
>
>
> > On Oct 17, 2024, at 1:20 PM, Jarkko Sakkinen <jarkko@kernel.org>
> > wrote:
> >
> > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> > > Add a new verification type called VERIFYING_CLAVIS_SIGNATURE.
> > > This
> > > new
> > > usage will be used for validating keys added to the new clavis
> > > LSM
> > > keyring.
> > > This will be introduced in a follow-on patch.
> > >
> > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> > > ---
> > > crypto/asymmetric_keys/asymmetric_type.c | 1 +
> > > crypto/asymmetric_keys/pkcs7_verify.c | 1 +
> > > include/linux/verification.h | 2 ++
> > > 3 files changed, 4 insertions(+)
> > >
> > > diff --git a/crypto/asymmetric_keys/asymmetric_type.c
> > > b/crypto/asymmetric_keys/asymmetric_type.c
> > > index 43af5fa510c0..d7bf95c77f4a 100644
> > > --- a/crypto/asymmetric_keys/asymmetric_type.c
> > > +++ b/crypto/asymmetric_keys/asymmetric_type.c
> > > @@ -25,6 +25,7 @@ const char *const
> > > key_being_used_for[NR__KEY_BEING_USED_FOR] = {
> > > [VERIFYING_KEY_SIGNATURE] = "key sig",
> > > [VERIFYING_KEY_SELF_SIGNATURE] = "key self sig",
> > > [VERIFYING_UNSPECIFIED_SIGNATURE] = "unspec sig",
> > > + [VERIFYING_CLAVIS_SIGNATURE] = "clavis sig",
> > > };
> > > EXPORT_SYMBOL_GPL(key_being_used_for);
> > >
> > > diff --git a/crypto/asymmetric_keys/pkcs7_verify.c
> > > b/crypto/asymmetric_keys/pkcs7_verify.c
> > > index f0d4ff3c20a8..1dc80e68ce96 100644
> > > --- a/crypto/asymmetric_keys/pkcs7_verify.c
> > > +++ b/crypto/asymmetric_keys/pkcs7_verify.c
> > > @@ -428,6 +428,7 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
> > > }
> > > /* Authattr presence checked in parser */
> > > break;
> > > + case VERIFYING_CLAVIS_SIGNATURE:
> > > case VERIFYING_UNSPECIFIED_SIGNATURE:
> > > if (pkcs7->data_type != OID_data) {
> > > pr_warn("Invalid unspecified sig (not pkcs7-
> > > data)\n");
> > > diff --git a/include/linux/verification.h
> > > b/include/linux/verification.h
> > > index cb2d47f28091..02d2d70e2324 100644
> > > --- a/include/linux/verification.h
> > > +++ b/include/linux/verification.h
> > > @@ -36,6 +36,8 @@ enum key_being_used_for {
> > > VERIFYING_KEY_SIGNATURE,
> > > VERIFYING_KEY_SELF_SIGNATURE,
> > > VERIFYING_UNSPECIFIED_SIGNATURE,
> > > + /* Add new entries above, keep VERIFYING_CLAVIS_SIGNATURE at
> > > the end. */
> > > + VERIFYING_CLAVIS_SIGNATURE,
> > > NR__KEY_BEING_USED_FOR
> > > };
> > > extern const char *const
> > > key_being_used_for[NR__KEY_BEING_USED_FOR];
> >
> > This looks as good as it can get. Just wondering that does this
> > Clavis
> > thing connect with the TPM2 asymmetric keys that I've been working
> > on?
> > I.e. can they be used in tandem. I should really update that patch
> > set
> > (latest from April).
>
> With some changes, I think they could be used in tandem. If I'm
> looking at
> the correct series, tpm2_key_rsa_describe would need to be changed to
> return a unique identifier, instead of "TPM2/RSA". This identifier
> could be
> used instead of the skid when creating a Clavis ACL. There would
> probably
> also need to be a new system kernel keyring containing these TPM
> keys.
> Similar to the builtin, secondary, machine, etc.
I think when I finally get into working on this again I focus on
purely to get ECDSA right. Thanks for the tip, most likely this
revamp will happen post your patch set. I'm still busy fixing
corner cases with the bus encryption that James Bottomley
contributed.
BR, Jarkko
next prev parent reply other threads:[~2024-10-17 21:58 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 15:55 [RFC PATCH v3 00/13] Clavis LSM Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check Eric Snowberg
2024-10-17 16:13 ` Jarkko Sakkinen
2024-10-17 16:50 ` Eric Snowberg
2024-12-23 13:21 ` Mimi Zohar
2025-01-03 23:15 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key Eric Snowberg
2024-10-17 16:16 ` Jarkko Sakkinen
2024-10-17 16:53 ` Eric Snowberg
2024-12-23 16:11 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis Eric Snowberg
2024-10-17 16:50 ` Jarkko Sakkinen
2024-10-17 20:34 ` Eric Snowberg
2024-10-17 21:16 ` Jarkko Sakkinen
2024-12-24 0:01 ` Mimi Zohar
2025-01-03 23:27 ` Eric Snowberg
2025-01-05 11:43 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE) Eric Snowberg
2024-10-17 19:20 ` Jarkko Sakkinen
2024-10-17 21:42 ` Eric Snowberg
2024-10-17 21:58 ` Jarkko Sakkinen [this message]
2024-12-24 0:17 ` Mimi Zohar
2025-01-03 23:28 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl Eric Snowberg
2024-10-18 5:21 ` Ben Boeckel
2024-10-18 15:42 ` Eric Snowberg
2024-10-18 16:55 ` Ben Boeckel
2024-10-18 21:55 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 06/13] clavis: Populate clavis keyring acl with kernel module signature Eric Snowberg
2024-10-17 19:27 ` Jarkko Sakkinen
2024-10-17 15:55 ` [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key Eric Snowberg
2025-02-06 20:13 ` Jarkko Sakkinen
2025-02-07 23:09 ` Eric Snowberg
2025-02-12 12:42 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis Eric Snowberg
2024-10-23 2:25 ` sergeh
2024-10-23 19:25 ` Eric Snowberg
2024-10-24 19:57 ` sergeh
2024-12-24 17:43 ` Mimi Zohar
2025-01-03 23:32 ` Eric Snowberg
2025-01-05 12:59 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 09/13] clavis: Allow user to define acl at build time Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 10/13] efi: Make clavis boot param persist across kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 11/13] clavis: Prevent boot param change during kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 12/13] clavis: Add function redirection for Kunit support Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 13/13] clavis: " Eric Snowberg
2024-12-24 1:11 ` Mimi Zohar
2024-12-23 12:09 ` [RFC PATCH v3 00/13] Clavis LSM Mimi Zohar
2025-01-03 23:14 ` Eric Snowberg
2025-01-04 4:48 ` Paul Moore
2025-01-06 3:40 ` Paul Moore
2025-01-06 17:15 ` Eric Snowberg
2025-02-27 20:41 ` Mimi Zohar
2025-02-27 22:22 ` Paul Moore
2025-02-28 14:08 ` Mimi Zohar
2025-02-28 16:14 ` Paul Moore
2025-02-28 17:18 ` Mimi Zohar
2025-03-03 22:38 ` Paul Moore
2025-03-04 12:53 ` Mimi Zohar
2025-03-05 0:19 ` Paul Moore
2025-03-05 1:49 ` Mimi Zohar
2025-03-05 2:09 ` Paul Moore
2025-03-05 2:20 ` Mimi Zohar
2025-03-05 2:24 ` Paul Moore
2025-02-28 17:51 ` Eric Snowberg
2025-03-03 22:40 ` Paul Moore
2025-03-04 14:46 ` Eric Snowberg
2025-03-05 0:23 ` Paul Moore
2025-03-05 21:29 ` Eric Snowberg
2025-03-06 1:12 ` Paul Moore
2025-03-06 22:28 ` Eric Snowberg
2025-03-07 2:46 ` Paul Moore
2025-03-20 16:24 ` Eric Snowberg
2025-03-20 21:36 ` Paul Moore
2025-03-21 16:37 ` Eric Snowberg
2025-03-21 18:57 ` Paul Moore
2025-03-21 21:20 ` Eric Snowberg
2025-03-21 22:13 ` Paul Moore
2025-03-21 22:56 ` Eric Snowberg
2025-03-22 2:00 ` Paul Moore
2025-03-21 17:22 ` Jarkko Sakkinen
2025-03-21 19:05 ` Paul Moore
2025-03-20 22:40 ` James Bottomley
2025-03-21 16:40 ` Eric Snowberg
2025-03-21 16:55 ` James Bottomley
2025-03-21 20:15 ` Eric Snowberg
2025-03-21 20:53 ` James Bottomley
2025-03-24 17:44 ` Eric Snowberg
2025-03-21 17:08 ` Jarkko Sakkinen
2025-03-04 22:24 ` Jarkko Sakkinen
2025-03-05 0:25 ` Paul Moore
2025-03-05 0:29 ` Jarkko Sakkinen
2025-03-01 2:20 ` Jarkko Sakkinen
2025-03-01 2:19 ` 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=2e696bea1657b6c1a9309be7aa0e217fec47b750.camel@kernel.org \
--to=jarkko@kernel.org \
--cc=ardb@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=rdunlap@infradead.org \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=stefanb@linux.ibm.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
all inboxes | Powered by JetHome®