linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Boeckel <me@benboeckel.net>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: linux-security-module@vger.kernel.org, dhowells@redhat.com,
	dwmw2@infradead.org, herbert@gondor.apana.org.au,
	davem@davemloft.net, ardb@kernel.org, jarkko@kernel.org,
	paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
	zohar@linux.ibm.com, roberto.sassu@huawei.com,
	dmitry.kasatkin@gmail.com, mic@digikod.net,
	casey@schaufler-ca.com, stefanb@linux.ibm.com,
	ebiggers@kernel.org, rdunlap@infradead.org,
	linux-kernel@vger.kernel.org, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-integrity@vger.kernel.org
Subject: Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl
Date: Fri, 18 Oct 2024 01:21:44 -0400	[thread overview]
Message-ID: <ZxHwaGeDCBSp3Dzx@farprobe> (raw)
In-Reply-To: <20241017155516.2582369-6-eric.snowberg@oracle.com>

On Thu, Oct 17, 2024 at 09:55:08 -0600, Eric Snowberg wrote:
> Introduce a new key type for keyring access control.  The new key type
> is called clavis_key_acl.  The clavis_key_acl contains the subject key
> identifier along with the allowed usage type for the key.
> 
> The format is as follows:
> 
> XX:YYYYYYYYYYY
> 
> XX - Single byte of the key type
> 	VERIFYING_MODULE_SIGNATURE            00
> 	VERIFYING_FIRMWARE_SIGNATURE          01
> 	VERIFYING_KEXEC_PE_SIGNATURE          02
> 	VERIFYING_KEY_SIGNATURE               03
> 	VERIFYING_KEY_SELF_SIGNATURE          04
> 	VERIFYING_UNSPECIFIED_SIGNATURE       05
> :  - ASCII colon
> YY - Even number of hexadecimal characters representing the key id

This is expected to be *lowercase* hexadecimal characters in the code;
can that restriction please be documented? (Coming back here, there is a
`tolower` pass performed when copying from userspace, so this seems to
be an internal requirement, not userspace. Might be worth documenting
somewhere in case the kernel wants to make such a key internally.)

I also see a 32-byte (64 hex characters) limit in the code; that should
also be documented somewhere.

> This key type will be used in the clavis keyring for access control. To
> be added to the clavis keyring, the clavis_key_acl must be S/MIME signed
> by the sole asymmetric key contained within it.
> 
> Below is an example of how this could be used. Within the example, the
> key (b360d113c848ace3f1e6a80060b43d1206f0487d) is already in the machine
> keyring. The intended usage for this key is to validate a signed kernel
> for kexec:
> 
> echo "02:b360d113c848ace3f1e6a80060b43d1206f0487d" > kernel-acl.txt
> 
> The next step is to sign it:
> 
> openssl smime -sign -signer clavis-lsm.x509 -inkey clavis-lsm.priv -in \
> 	kernel-acl.txt  -out kernel-acl.pkcs7 -binary -outform DER \
> 	-nodetach -noattr
> 
> The final step is how to add the acl to the .clavis keyring:
> 
> keyctl padd clavis_key_acl "" %:.clavis < kernel-acl.pkcs7
> 
> Afterwards the new clavis_key_acl can be seen in the .clavis keyring:
> 
> keyctl show %:.clavis
> Keyring
>   keyring: .clavis
>    \_ asymmetric: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
>    \_ clavis_key_acl: 02:b360d113c848ace3f1e6a80060b43d1206f0487d

Can this be committed to `Documentation/` and not just the Git history
please?

Code comments inline below.

> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  security/clavis/clavis.h         |   1 +
>  security/clavis/clavis_keyring.c | 173 +++++++++++++++++++++++++++++++
>  2 files changed, 174 insertions(+)
> 
> diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
> index 5e397b55a60a..7b55a6050440 100644
> --- a/security/clavis/clavis.h
> +++ b/security/clavis/clavis.h
> @@ -5,6 +5,7 @@
>  
>  /* Max length for the asymmetric key id contained on the boot param */
>  #define CLAVIS_BIN_KID_MAX   32
> +#define CLAVIS_ASCII_KID_MAX 64
>  
>  struct asymmetric_setup_kid {
>  	struct asymmetric_key_id id;
> diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
> index 400ed455a3a2..00163e7f0fe9 100644
> --- a/security/clavis/clavis_keyring.c
> +++ b/security/clavis/clavis_keyring.c
> @@ -2,8 +2,12 @@
>  
>  #include <linux/security.h>
>  #include <linux/integrity.h>
> +#include <linux/ctype.h>
>  #include <keys/asymmetric-type.h>
> +#include <keys/asymmetric-subtype.h>
>  #include <keys/system_keyring.h>
> +#include <keys/user-type.h>
> +#include <crypto/pkcs7.h>
>  #include "clavis.h"
>  
>  static struct key *clavis_keyring;
> @@ -11,10 +15,173 @@ static struct asymmetric_key_id *clavis_boot_akid;
>  static struct asymmetric_setup_kid clavis_setup_akid;
>  static bool clavis_enforced;
>  
> +static int pkcs7_preparse_content(void *ctx, const void *data, size_t len, size_t asn1hdrlen)
> +{
> +	struct key_preparsed_payload *prep = ctx;
> +	const void *saved_prep_data;
> +	size_t saved_prep_datalen;
> +	char *desc;
> +	int ret, i;
> +
> +	/* key_acl_free_preparse will free this */
> +	desc = kmemdup(data, len, GFP_KERNEL);
> +	if (!desc)
> +		return -ENOMEM;
> +
> +	/* Copy the user supplied contents and remove any white space. */
> +	for (i = 0; i < len; i++) {
> +		desc[i] = tolower(desc[i]);

Ah, looking here it seems that userspace can provide upper or lowercase.
THat this is being performed should be added to the comment here.

> +		if (isspace(desc[i]))
> +			desc[i] = 0;

How is setting a space to `0` *removing* it? Surely the `isxdigit` check
internally is going to reject this. Perhaps you meant to have two
indices into `desc`, one read and one write and to stall the write index
as long as we're reading whitespace?

Also, that whitespace is stripped is a userspace-relevant detail that
should be documented.

> +static void key_acl_destroy(struct key *key)
> +{
> +	/* It should not be possible to get here */
> +	pr_info("destroy clavis_key_acl denied\n");
> +}
> +
> +static void key_acl_revoke(struct key *key)
> +{
> +	/* It should not be possible to get here */
> +	pr_info("revoke clavis_key_acl denied\n");
> +}

These keys cannot be destroyed or revoked? This seems…novel to me. What
if there's a timeout on the key? If such keys are immortal, timeouts
should also be refused?

> +static int key_acl_vet_description(const char *desc)
> +{
> +	int i, desc_len;
> +	s16 ktype;
> +
> +	if (!desc)
> +		goto invalid;
> +
> +	desc_len = sizeof(desc);

This should be `strlen`, no?

> +	/*
> +	 * clavis_acl format:
> +	 *    xx:yyyy...
> +	 *
> +	 *    xx     - Single byte of the key type
> +	 *    :      - Ascii colon
> +	 *    yyyy.. - Even number of hexadecimal characters representing the keyid
> +	 */
> +
> +	/* The min clavis acl is 7 characters. */
> +	if (desc_len < 7)
> +		goto invalid;
> +
> +	/* Check the first byte is a valid key type. */
> +	if (sscanf(desc, "%2hx", &ktype) != 1)
> +		goto invalid;
> +
> +	if (ktype >= VERIFYING_CLAVIS_SIGNATURE)
> +		goto invalid;
> +
> +	/* Check that there is a colon following the key type */
> +	if (desc[2] != ':')
> +		goto invalid;
> +
> +	/* Move past the colon. */
> +	desc += 3;
> +
> +	for (i = 0; *desc && i < CLAVIS_ASCII_KID_MAX; desc++, i++) {
> +		/* Check if lowercase hex number */
> +		if (!isxdigit(*desc) || isupper(*desc))
> +			goto invalid;
> +	}
> +
> +	/* Check if the has is greater than CLAVIS_ASCII_KID_MAX. */
> +	if (*desc)
> +		goto invalid;
> +
> +	/* Check for even number of hex characters. */
> +	if (i == 0 || i & 1)

FWIW< the `i == 0` is impossible due to the `desc_len < 7` check above
(well, once `strlen` is used…).

Thanks,

--Ben

  reply	other threads:[~2024-10-18  5:21 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
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 [this message]
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=ZxHwaGeDCBSp3Dzx@farprobe \
    --to=me@benboeckel.net \
    --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=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;
as well as URLs for NNTP newsgroup(s).