All of lore.kernel.org
 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: 95+ 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-10-21  7:45   ` kernel test robot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.