mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
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: Thu, 17 Oct 2024 21:42:19 +0000	[thread overview]
Message-ID: <46017A8E-88EB-4B8D-9FB2-643F9A5BF7F0@oracle.com> (raw)
In-Reply-To: <24f4db65f9417b5a686b642bf5a8559236efafb9.camel@kernel.org>



> 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.


  reply	other threads:[~2024-10-17 21:47 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 [this message]
2024-10-17 21:58       ` Jarkko Sakkinen
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=46017A8E-88EB-4B8D-9FB2-643F9A5BF7F0@oracle.com \
    --to=eric.snowberg@oracle.com \
    --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=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --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®