[RFC PATCH v3 00/13] Clavis LSM

[RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

Motivation:

Each end-user has their own security threat model. What is important to one
end-user may not be important to another. There is not a right or wrong threat
model.

A common request made when adding new kernel changes that could impact the
threat model around system kernel keys is to add additional Kconfig options.
As kernel developers, it is challenging to both add and keep track of all the
Kconfig options around security features that may limit or restrict
system key usage.  It is also difficult for a general purpose distro to take
advantage of some of these features, since it may prevent some users from
executing their workload.

It is the author's belief that it is better left up to the end-user on how
kernel keys should be used within their system.

Throughout the Linux kernel, key usage is tracked when doing signature
verification with keys contained within one of the system keyrings;  however,
there isn't a way for the end-user to enforce this usage.  This series gives the
end-user the ability to configure key usage based on their threat model.
Having the ability to enforce key usage also improves security by reducing the
attack surface should a system key be compromised. It allows new features to be
added without the need for additional Kconfig options for fear of changing the
end-user's threat model. It also allows a distro to build a kernel that suits
various end-user's needs without resorting to selecting Kconfig options with
the least restrictive security options.

Solution:

This series introduces a new LSM called Clavis (Latin word meaning key).
This LSM leaves it up to the end-user to determine what system keys they want
to use and for what purpose.

The Clavis LSM adds the ability to do access control for all system keys.  When
enabled, until an ACL entry is added for a specific key, none of the system keys
may be used for any type of verification purpose.  When the kernel is built,
typically kernel modules are signed with an ephemeral key, an ACL entry for the
ephemeral key is pre-loaded, allowing the kernel modules to load during boot. At
build time other ACL entries may also be included.

The Clavis LSM requires the end-user to have their own public key infrastructure
(PKI).  In order for a Clavis ACL entry to be added, the ACL must be signed by
what is being called the Clavis key.  The Clavis key is owned by the end-user.
The Clavis public key can be contained within the machine keyring, or it can be
added after the machine boots.

Not only is there a new Clavis key being introduced, but there is also a new
.clavis keyring.  The .clavis keyring contains a single Clavis key. It also
contains any number of ACL entries that are signed by the Clavis key.

It is believed that the most common setup would be to have the Clavis key
contained within the machine keyring. Enabling the Clavis LSM during boot is
accomplished by passing in the asymmetric key id for the Clavis key within a
new "clavis=" boot param.  The asymmetric key id must match one already
contained within any of the system keyrings.  If a match is found, a link is
created into the new .clavis keyring.  This Clavis key shall be used as the
root of trust for any keyring ACL updates afterwards.

On UEFI systems the "clavis" boot param is mirrored into a new UEFI variable
within the EFI stub code. This variable will persist until the next reboot.
This same type of functionality is done within shim. Since this variable is
created before ExitBootServices (EBS) it will not have the NVRAM bit set,
signifying it was created during the Boot Services phase. This is being used
so the "clavis" boot param can not be changed via kexec, thereby preventing a
pivot of the root of trust.

As mentioned earlier, this LSM introduces a new .clavis keyring.  Following
boot, no new keys can be added to this keyring and only the key designated via
the initial boot param may be used. If the clavis boot param was not used, the
LSM can be enabled afterwards using the keyctl command.  The end-user may add
their Clavis key into the .clavis keyring and the Clavis LSM shall be enabled.

The .clavis keyring also holds the access control list for system keys. A new
key type called clavis_key_acl is being introduced. This contains the usage
followed by the asymmetric key id. To be added to the clavis keyring, the
clavis_key_acl must be S/MIME signed by the Clavis key. New ACL additions to
the .clavis keyring may be added at any time.

Currently this LSM does not require new changes or modifications to any user
space tools.  It also does not have a securityfs interface.  Everything is
done using the existing keyctl tool through the new .clavis keyring. The
S/MIME signing can be done with a simple OpenSSL command. If additions or
updates need to be added in the future, new ACL key types could be created.
With this approach, maintainability should not be an issue in the future
if missing items are identified.

Clavis must be configured at build time with CONFIG_SECURITY_CLAVIS=y. The list
of security modules enabled by default is set with CONFIG_LSM.  The kernel
configuration must contain CONFIG_LSM=[...],clavis with [...] as the list of
other security modules for the running system.

For setup and usage instructions, a clavis admin-guide has been included
in Documentation/admin-guide/LSM/clavis.rst.

Future enhancements to this LSM could include:

1. Subsystems that currently use system keys with
   VERIFYING_UNSPECIFIED_SIGNATURE could be updated with their specific usage
   type.  For example, a usage type for IMA, BPF, etc could be added.

2. Having the ability to allow platform keys to be on par with all other
   system keys when using this LSM. This would be useful for a user that
   controls their entire UEFI SB DB key chain and doesn't want to use MOK keys.
   This could also potentially remove the need for the machine keyring all
   together.

3. Some of the Kconfig options around key usage and types could be deprecated.

I would appreciate any feedback on this approach. Thanks.

Changes in v3:
  Rebased to 6.12-rc3
  Added Kunit test code
  Preload an ACL in the clavis keyring with the ephemeral module signing key
  Preload user defined ACL data into the clavis keyring with build time data
  Changes to the second patch recommended by Jarkko
  Reordered patches recommended by Mimi
  Documentation improvements recommended by Randy

Changes in v2:
  Rebased to 6.10-rc1
  Various cleanup in the first patch recommended by Jarkko
  Documentation improvements recommended by Randy
  Fixed lint warnings
  Other cleanup

Eric Snowberg (13):
  certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check
  certs: Introduce ability to link to a system key
  clavis: Introduce a new system keyring called clavis
  keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)
  clavis: Introduce a new key type called clavis_key_acl
  clavis: Populate clavis keyring acl with kernel module signature
  keys: Add ability to track intended usage of the public key
  clavis: Introduce new LSM called clavis
  clavis: Allow user to define acl at build time
  efi: Make clavis boot param persist across kexec
  clavis: Prevent boot param change during kexec
  clavis: Add function redirection for Kunit support
  clavis: Kunit support

 Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++
 .../admin-guide/kernel-parameters.txt         |   6 +
 MAINTAINERS                                   |   7 +
 certs/.gitignore                              |   1 +
 certs/Makefile                                |  20 +
 certs/blacklist.c                             |   3 +
 certs/clavis_module_acl.c                     |   7 +
 certs/system_keyring.c                        |  36 +-
 crypto/asymmetric_keys/asymmetric_type.c      |   1 +
 crypto/asymmetric_keys/pkcs7_trust.c          |  20 +
 crypto/asymmetric_keys/pkcs7_verify.c         |   5 +
 crypto/asymmetric_keys/signature.c            |   4 +
 drivers/firmware/efi/Kconfig                  |  12 +
 drivers/firmware/efi/libstub/Makefile         |   1 +
 drivers/firmware/efi/libstub/clavis.c         |  33 +
 .../firmware/efi/libstub/efi-stub-helper.c    |   2 +
 drivers/firmware/efi/libstub/efi-stub.c       |   2 +
 drivers/firmware/efi/libstub/efistub.h        |   8 +
 drivers/firmware/efi/libstub/x86-stub.c       |   2 +
 include/crypto/pkcs7.h                        |   3 +
 include/crypto/public_key.h                   |   4 +
 include/keys/system_keyring.h                 |   7 +-
 include/linux/efi.h                           |   1 +
 include/linux/integrity.h                     |   8 +
 include/linux/lsm_count.h                     |   8 +-
 include/linux/lsm_hook_defs.h                 |   2 +
 include/linux/security.h                      |   7 +
 include/linux/verification.h                  |   2 +
 include/uapi/linux/lsm.h                      |   1 +
 security/Kconfig                              |  11 +-
 security/Makefile                             |   1 +
 security/clavis/.gitignore                    |   2 +
 security/clavis/.kunitconfig                  |   4 +
 security/clavis/Kconfig                       |  37 ++
 security/clavis/Makefile                      | 156 +++++
 security/clavis/clavis.c                      |  26 +
 security/clavis/clavis.h                      |  62 ++
 security/clavis/clavis_builtin_acl.c          |   7 +
 security/clavis/clavis_efi.c                  |  50 ++
 security/clavis/clavis_keyring.c              | 426 +++++++++++++
 security/clavis/clavis_test.c                 | 566 ++++++++++++++++++
 security/integrity/iint.c                     |   2 +
 security/security.c                           |  13 +
 .../selftests/lsm/lsm_list_modules_test.c     |   3 +
 44 files changed, 1757 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/admin-guide/LSM/clavis.rst
 create mode 100644 certs/clavis_module_acl.c
 create mode 100644 drivers/firmware/efi/libstub/clavis.c
 create mode 100644 security/clavis/.gitignore
 create mode 100644 security/clavis/.kunitconfig
 create mode 100644 security/clavis/Kconfig
 create mode 100644 security/clavis/Makefile
 create mode 100644 security/clavis/clavis.c
 create mode 100644 security/clavis/clavis.h
 create mode 100644 security/clavis/clavis_builtin_acl.c
 create mode 100644 security/clavis/clavis_efi.c
 create mode 100644 security/clavis/clavis_keyring.c
 create mode 100644 security/clavis/clavis_test.c


base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354
-- 
2.45.0

[RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check

[Eric Snowberg]

Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this
pattern does not need to be repeated with new code.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 certs/system_keyring.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 9de610bf1f4b..e344cee10d28 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys;
 #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
 static struct key *machine_trusted_keys;
 #endif
-#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
 static struct key *platform_trusted_keys;
-#endif
 
 extern __initconst const u8 system_certificate_list[];
 extern __initconst const unsigned long system_certificate_list_size;
@@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
 		trusted_keys = builtin_trusted_keys;
 #endif
 	} else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
-#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
 		trusted_keys = platform_trusted_keys;
-#else
-		trusted_keys = NULL;
-#endif
 		if (!trusted_keys) {
 			ret = -ENOKEY;
 			pr_devel("PKCS#7 platform keyring is not available\n");
-- 
2.45.0

[RFC PATCH v3 02/13] certs: Introduce ability to link to a system key

[Eric Snowberg]

Introduce system_key_link(), a new function to allow a keyring to link
to a key contained within one of the system keyrings (builtin, secondary,
or platform). Depending on how the kernel is built, if the machine
keyring is available, it will be checked as well, since it is linked to
the secondary keyring. If the asymmetric key id matches a key within one
of these system keyrings, the matching key is linked into the passed in
keyring.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 certs/system_keyring.c        | 30 ++++++++++++++++++++++++++++++
 include/keys/system_keyring.h |  7 ++++++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index e344cee10d28..4abee7514442 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -20,6 +20,9 @@
 static struct key *builtin_trusted_keys;
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
 static struct key *secondary_trusted_keys;
+#define system_trusted_keys secondary_trusted_keys
+#else
+#define system_trusted_keys builtin_trusted_keys
 #endif
 #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
 static struct key *machine_trusted_keys;
@@ -420,3 +423,30 @@ void __init set_platform_trusted_keys(struct key *keyring)
 	platform_trusted_keys = keyring;
 }
 #endif
+
+/**
+ * system_key_link - Link to a system key
+ * @keyring: The keyring to link into
+ * @id: The asymmetric key id to look for in the system keyring
+ *
+ * Search the system keyrings to see if one of them contains a matching "id".
+ * If there is a match, link the key into "keyring".  System keyrings always
+ * includes the builtin. If any of the following keyrings are enabled:
+ * secondary, machine, and platform they are searched as well.
+ */
+int system_key_link(struct key *keyring, struct asymmetric_key_id *id)
+{
+	struct key *key;
+
+	key = find_asymmetric_key(system_trusted_keys, id, NULL, NULL, false);
+	if (!IS_ERR(key))
+		return key_link(keyring, key);
+
+	if (platform_trusted_keys) {
+		key = find_asymmetric_key(platform_trusted_keys, id, NULL, NULL, false);
+		if (!IS_ERR(key))
+			return key_link(keyring, key);
+	}
+
+	return -ENOKEY;
+}
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 8365adf842ef..b47ac8e2001a 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -9,6 +9,7 @@
 #define _KEYS_SYSTEM_KEYRING_H
 
 #include <linux/key.h>
+struct asymmetric_key_id;
 
 enum blacklist_hash_type {
 	/* TBSCertificate hash */
@@ -28,7 +29,7 @@ int restrict_link_by_digsig_builtin(struct key *dest_keyring,
 				    const union key_payload *payload,
 				    struct key *restriction_key);
 extern __init int load_module_cert(struct key *keyring);
-
+extern int system_key_link(struct key *keyring, struct asymmetric_key_id *id);
 #else
 #define restrict_link_by_builtin_trusted restrict_link_reject
 #define restrict_link_by_digsig_builtin restrict_link_reject
@@ -38,6 +39,10 @@ static inline __init int load_module_cert(struct key *keyring)
 	return 0;
 }
 
+static inline int system_key_link(struct key *keyring, struct asymmetric_key_id *id)
+{
+	return 0;
+}
 #endif
 
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
-- 
2.45.0

[RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Eric Snowberg]

Introduce a new system keyring called clavis.  This keyring shall contain
a single asymmetric key. This key may be a linked to a key already
contained in one of the system keyrings (builtin, secondary, or platform).
One way to add this key into this keyring is during boot by passing in the
asymmetric key id within the new "clavis=" boot param.  If a matching key
is found in one of the system keyrings, a link shall be created. This
keyring will be used in the future by the new Clavis LSM.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 .../admin-guide/kernel-parameters.txt         |   6 +
 include/linux/integrity.h                     |   8 ++
 security/Kconfig                              |   1 +
 security/Makefile                             |   1 +
 security/clavis/Kconfig                       |  11 ++
 security/clavis/Makefile                      |   3 +
 security/clavis/clavis.h                      |  13 ++
 security/clavis/clavis_keyring.c              | 115 ++++++++++++++++++
 security/integrity/iint.c                     |   2 +
 9 files changed, 160 insertions(+)
 create mode 100644 security/clavis/Kconfig
 create mode 100644 security/clavis/Makefile
 create mode 100644 security/clavis/clavis.h
 create mode 100644 security/clavis/clavis_keyring.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1518343bbe22..d71397e7d254 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -645,6 +645,12 @@
 	cio_ignore=	[S390]
 			See Documentation/arch/s390/common_io.rst for details.
 
+	clavis=		[SECURITY,EARLY]
+			Identifies a specific key contained in one of the system
+			keyrings (builtin, secondary, or platform) to be used as
+			the Clavis root of trust.
+			Format: { <keyid> }
+
 	clearcpuid=X[,X...] [X86]
 			Disable CPUID feature X for the kernel. See
 			arch/x86/include/asm/cpufeatures.h for the valid bit
diff --git a/include/linux/integrity.h b/include/linux/integrity.h
index f5842372359b..837c52e1d83b 100644
--- a/include/linux/integrity.h
+++ b/include/linux/integrity.h
@@ -23,6 +23,14 @@ enum integrity_status {
 #ifdef CONFIG_INTEGRITY
 extern void __init integrity_load_keys(void);
 
+#ifdef CONFIG_SECURITY_CLAVIS
+void __init late_init_clavis_setup(void);
+#else
+static inline void late_init_clavis_setup(void)
+{
+}
+#endif
+
 #else
 static inline void integrity_load_keys(void)
 {
diff --git a/security/Kconfig b/security/Kconfig
index 28e685f53bd1..714ec08dda96 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -225,6 +225,7 @@ source "security/safesetid/Kconfig"
 source "security/lockdown/Kconfig"
 source "security/landlock/Kconfig"
 source "security/ipe/Kconfig"
+source "security/clavis/Kconfig"
 
 source "security/integrity/Kconfig"
 
diff --git a/security/Makefile b/security/Makefile
index cc0982214b84..69576551007a 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_CGROUPS)			+= device_cgroup.o
 obj-$(CONFIG_BPF_LSM)			+= bpf/
 obj-$(CONFIG_SECURITY_LANDLOCK)		+= landlock/
 obj-$(CONFIG_SECURITY_IPE)		+= ipe/
+obj-$(CONFIG_SECURITY_CLAVIS)		+= clavis/
 
 # Object integrity file lists
 obj-$(CONFIG_INTEGRITY)			+= integrity/
diff --git a/security/clavis/Kconfig b/security/clavis/Kconfig
new file mode 100644
index 000000000000..04f7565f2e2b
--- /dev/null
+++ b/security/clavis/Kconfig
@@ -0,0 +1,11 @@
+config SECURITY_CLAVIS
+	bool "Clavis keyring"
+	depends on SECURITY
+	select SYSTEM_DATA_VERIFICATION
+	select CRYPTO_SHA256
+	help
+	  Enable the clavis keyring. This keyring shall contain a single asymmetric key.
+	  This key shall be linked to a key already contained in one of the system
+	  keyrings (builtin, secondary, or platform).  One way to add this key
+	  is during boot by passing in the asymmetric key id within the "clavis=" boot
+	  param.  This keyring is required by the Clavis LSM.
diff --git a/security/clavis/Makefile b/security/clavis/Makefile
new file mode 100644
index 000000000000..16c451f45f37
--- /dev/null
+++ b/security/clavis/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
new file mode 100644
index 000000000000..5e397b55a60a
--- /dev/null
+++ b/security/clavis/clavis.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _SECURITY_CLAVIS_H_
+#define _SECURITY_CLAVIS_H_
+#include <keys/asymmetric-type.h>
+
+/* Max length for the asymmetric key id contained on the boot param */
+#define CLAVIS_BIN_KID_MAX   32
+
+struct asymmetric_setup_kid {
+	struct asymmetric_key_id id;
+	unsigned char data[CLAVIS_BIN_KID_MAX];
+};
+#endif /* _SECURITY_CLAVIS_H_ */
diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
new file mode 100644
index 000000000000..400ed455a3a2
--- /dev/null
+++ b/security/clavis/clavis_keyring.c
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/security.h>
+#include <linux/integrity.h>
+#include <keys/asymmetric-type.h>
+#include <keys/system_keyring.h>
+#include "clavis.h"
+
+static struct key *clavis_keyring;
+static struct asymmetric_key_id *clavis_boot_akid;
+static struct asymmetric_setup_kid clavis_setup_akid;
+static bool clavis_enforced;
+
+static bool clavis_acl_enforced(void)
+{
+	return clavis_enforced;
+}
+static int restrict_link_for_clavis(struct key *dest_keyring, const struct key_type *type,
+				    const union key_payload *payload, struct key *restrict_key)
+{
+	/*
+	 * Allow a single asymmetric key into this keyring. This key is used as the
+	 * root of trust for anything added afterwards.
+	 */
+	if (type == &key_type_asymmetric && dest_keyring == clavis_keyring &&
+	    !clavis_acl_enforced()) {
+		clavis_enforced = true;
+		return 0;
+	}
+
+	return -EOPNOTSUPP;
+}
+
+static struct asymmetric_key_id *clavis_parse_boot_param(char *kid, struct asymmetric_key_id *akid,
+							 int akid_max_len)
+{
+	int error, hex_len;
+
+	if (!kid)
+		return 0;
+
+	hex_len = strlen(kid) / 2;
+
+	if (hex_len > akid_max_len)
+		return 0;
+
+	akid->len = hex_len;
+	error = hex2bin(akid->data, kid, akid->len);
+
+	if (error < 0) {
+		pr_err("Unparsable clavis key id\n");
+		return 0;
+	}
+
+	return akid;
+}
+
+static int __init clavis_param(char *kid)
+{
+	clavis_boot_akid = clavis_parse_boot_param(kid, &clavis_setup_akid.id,
+						   ARRAY_SIZE(clavis_setup_akid.data));
+
+	return 1;
+}
+
+__setup("clavis=", clavis_param);
+
+static struct key *clavis_keyring_alloc(const char *desc, struct key_restriction *restriction)
+{
+	struct key *keyring;
+
+	keyring = keyring_alloc(desc, GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
+				KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH | KEY_POS_WRITE |
+				KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH | KEY_USR_WRITE,
+				KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP,
+				restriction, NULL);
+	return keyring;
+}
+
+static struct key_restriction *clavis_restriction_alloc(key_restrict_link_func_t check_func)
+{
+	struct key_restriction *restriction;
+
+	restriction = kzalloc(sizeof(*restriction), GFP_KERNEL);
+
+	if (restriction)
+		restriction->check = check_func;
+
+	return restriction;
+}
+
+static int __init clavis_keyring_init(void)
+{
+	struct key_restriction *restriction;
+
+	restriction = clavis_restriction_alloc(restrict_link_for_clavis);
+	if (!restriction)
+		panic("Can't allocate clavis keyring restriction\n");
+
+	clavis_keyring = clavis_keyring_alloc(".clavis", restriction);
+	if (IS_ERR(clavis_keyring))
+		panic("Can't allocate clavis keyring\n");
+
+	return 0;
+}
+
+void __init late_init_clavis_setup(void)
+{
+	clavis_keyring_init();
+
+	if (!clavis_boot_akid)
+		return;
+
+	system_key_link(clavis_keyring, clavis_boot_akid);
+}
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 068ac6c2ae1e..87a8bfc0662f 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -36,6 +36,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
  */
 void __init integrity_load_keys(void)
 {
+	late_init_clavis_setup();
+
 	ima_load_x509();
 
 	if (!IS_ENABLED(CONFIG_IMA_LOAD_X509))
-- 
2.45.0

[RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)

[Eric Snowberg]

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];
-- 
2.45.0

[RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl

[Eric Snowberg]

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

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]);
+		if (isspace(desc[i]))
+			desc[i] = 0;
+	}
+
+	prep->description = desc;
+	saved_prep_data = prep->data;
+	saved_prep_datalen = prep->datalen;
+	prep->data = desc;
+	prep->datalen = len;
+	ret = user_preparse(prep);
+	prep->data = saved_prep_data;
+	prep->datalen = saved_prep_datalen;
+	return ret;
+}
+
+static void key_acl_free_preparse(struct key_preparsed_payload *prep)
+{
+	kfree(prep->description);
+	user_free_preparse(prep);
+}
+
+static struct key *clavis_keyring_get(void)
+{
+	return clavis_keyring;
+}
+
 static bool clavis_acl_enforced(void)
 {
 	return clavis_enforced;
 }
+
+static int key_acl_preparse(struct key_preparsed_payload *prep)
+{
+	/*
+	 * Only allow the description to be set via the pkcs7 data contents.
+	 * The exception to this rule is if the entry was builtin, it will have
+	 * the original_description set.  Since we don't have access to the key
+	 * within the preparse step to determine if the entity is builtin, let
+	 * it through now and this will be checked in the instantiate step.
+	 */
+	if (prep->orig_description)
+		return 0;
+
+	return verify_pkcs7_signature(NULL, 0, prep->data, prep->datalen, clavis_keyring_get(),
+				      VERIFYING_CLAVIS_SIGNATURE, pkcs7_preparse_content,
+				      prep);
+}
+
+static int key_acl_instantiate(struct key *key, struct key_preparsed_payload *prep)
+{
+	/*
+	 * The orig_description may only be used for builtin entities.  All
+	 * other entries must have been validated through the pkcs7 signature
+	 * within the preparse stage.
+	 */
+	if (prep->orig_description && !(key->flags & (1 << KEY_FLAG_BUILTIN)))
+		return -EINVAL;
+
+	key->perm = KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH |
+		    KEY_USR_VIEW;
+	set_bit(KEY_FLAG_KEEP, &key->flags);
+	return generic_key_instantiate(key, prep);
+}
+
+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");
+}
+
+static int key_acl_update(struct key *key, struct key_preparsed_payload *prep)
+{
+	return -EPERM;
+}
+
+static int key_acl_vet_description(const char *desc)
+{
+	int i, desc_len;
+	s16 ktype;
+
+	if (!desc)
+		goto invalid;
+
+	desc_len = sizeof(desc);
+
+	/*
+	 * 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)
+		goto invalid;
+
+	return 0;
+
+invalid:
+	pr_err("Unparsable clavis key id: %s\n", desc);
+	return -EINVAL;
+}
+
+static struct key_type clavis_key_acl = {
+	.name			= "clavis_key_acl",
+	.preparse		= key_acl_preparse,
+	.free_preparse		= key_acl_free_preparse,
+	.instantiate		= key_acl_instantiate,
+	.update			= key_acl_update,
+	.revoke			= key_acl_revoke,
+	.destroy		= key_acl_destroy,
+	.vet_description	= key_acl_vet_description,
+	.read			= user_read,
+};
+
 static int restrict_link_for_clavis(struct key *dest_keyring, const struct key_type *type,
 				    const union key_payload *payload, struct key *restrict_key)
 {
@@ -28,6 +195,9 @@ static int restrict_link_for_clavis(struct key *dest_keyring, const struct key_t
 		return 0;
 	}
 
+	if (type == &clavis_key_acl)
+		return 0;
+
 	return -EOPNOTSUPP;
 }
 
@@ -93,6 +263,9 @@ static int __init clavis_keyring_init(void)
 {
 	struct key_restriction *restriction;
 
+	if (register_key_type(&clavis_key_acl) < 0)
+		panic("Can't allocate clavis key type\n");
+
 	restriction = clavis_restriction_alloc(restrict_link_for_clavis);
 	if (!restriction)
 		panic("Can't allocate clavis keyring restriction\n");
-- 
2.45.0

[RFC PATCH v3 06/13] clavis: Populate clavis keyring acl with kernel module signature

[Eric Snowberg]

If the kernel is built with CONFIG_MODULE_SIG_KEY, get the subject
key identifier and add an ACL for it within the .clavis keyring.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 certs/.gitignore                 |  1 +
 certs/Makefile                   | 20 ++++++++++++++++++++
 certs/clavis_module_acl.c        |  7 +++++++
 security/clavis/clavis.h         |  9 +++++++++
 security/clavis/clavis_keyring.c | 27 +++++++++++++++++++++++++++
 5 files changed, 64 insertions(+)
 create mode 100644 certs/clavis_module_acl.c

diff --git a/certs/.gitignore b/certs/.gitignore
index cec5465f31c1..dc99ae5a2585 100644
--- a/certs/.gitignore
+++ b/certs/.gitignore
@@ -3,3 +3,4 @@
 /extract-cert
 /x509_certificate_list
 /x509_revocation_list
+/module_acl
diff --git a/certs/Makefile b/certs/Makefile
index f6fa4d8d75e0..f2555e5296f5 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o
 obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o blacklist_hashes.o
 obj-$(CONFIG_SYSTEM_REVOCATION_LIST) += revocation_certificates.o
+obj-$(CONFIG_SECURITY_CLAVIS) += clavis_module_acl.o
 
 $(obj)/blacklist_hashes.o: $(obj)/blacklist_hash_list
 CFLAGS_blacklist_hashes.o := -I $(obj)
@@ -75,6 +76,25 @@ $(obj)/signing_key.x509: $(filter-out $(PKCS11_URI),$(CONFIG_MODULE_SIG_KEY)) $(
 
 targets += signing_key.x509
 
+ifeq ($(CONFIG_MODULE_SIG_KEY),)
+quiet_cmd_make_module_acl = GEN   $@
+      cmd_make_module_acl = \
+	echo > $@
+else
+quiet_cmd_make_module_acl = GEN   $@
+      cmd_make_module_acl = \
+	openssl x509 -in $< -inform der -ext subjectKeyIdentifier  -nocert | \
+	tail -n +2 | cut -f2 -d '='| tr -d ':' | tr '[:upper:]' '[:lower:]' | \
+	sed 's/^[ \t]*//; s/.*/"00:&",/' > $@
+endif
+
+$(obj)/module_acl: $(obj)/signing_key.x509 FORCE
+		$(call if_changed,make_module_acl)
+
+$(obj)/clavis_module_acl.o: $(obj)/module_acl
+
+targets += module_acl
+
 $(obj)/revocation_certificates.o: $(obj)/x509_revocation_list
 
 $(obj)/x509_revocation_list: $(CONFIG_SYSTEM_REVOCATION_KEYS) $(obj)/extract-cert FORCE
diff --git a/certs/clavis_module_acl.c b/certs/clavis_module_acl.c
new file mode 100644
index 000000000000..fc2f694c48f9
--- /dev/null
+++ b/certs/clavis_module_acl.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/kernel.h>
+
+const char __initconst *const clavis_module_acl[] = {
+#include "module_acl"
+	NULL
+};
diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
index 7b55a6050440..92f77a1939ad 100644
--- a/security/clavis/clavis.h
+++ b/security/clavis/clavis.h
@@ -11,4 +11,13 @@ struct asymmetric_setup_kid {
 	struct asymmetric_key_id id;
 	unsigned char data[CLAVIS_BIN_KID_MAX];
 };
+
+#ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
+const char __initconst *const clavis_module_acl[] = {
+	 NULL
+};
+#else
+extern const char __initconst *const clavis_module_acl[];
+#endif
+
 #endif /* _SECURITY_CLAVIS_H_ */
diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
index 00163e7f0fe9..2a18d0e77189 100644
--- a/security/clavis/clavis_keyring.c
+++ b/security/clavis/clavis_keyring.c
@@ -259,6 +259,31 @@ static struct key_restriction *clavis_restriction_alloc(key_restrict_link_func_t
 	return restriction;
 }
 
+static void clavis_add_acl(const char *const *skid_list, struct key *keyring)
+{
+	const char *const *acl;
+	key_ref_t key;
+
+	for (acl = skid_list; *acl; acl++) {
+		key = key_create(make_key_ref(keyring, true),
+				 "clavis_key_acl",
+				  *acl,
+				  NULL,
+				  0,
+				  KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH | KEY_USR_VIEW,
+				  KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_BUILT_IN |
+				  KEY_ALLOC_BYPASS_RESTRICTION);
+		if (IS_ERR(key)) {
+			if (PTR_ERR(key) == -EEXIST)
+				pr_info("Duplicate clavis_key_acl %s\n", *acl);
+			else
+				pr_info("Problem with clavis_key_acl %s: %pe\n", *acl, key);
+		} else {
+			pr_info("Added clavis_key_acl %s\n", *acl);
+		}
+	}
+}
+
 static int __init clavis_keyring_init(void)
 {
 	struct key_restriction *restriction;
@@ -274,6 +299,8 @@ static int __init clavis_keyring_init(void)
 	if (IS_ERR(clavis_keyring))
 		panic("Can't allocate clavis keyring\n");
 
+	clavis_add_acl(clavis_module_acl, clavis_keyring);
+
 	return 0;
 }
 
-- 
2.45.0

[RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key

[Eric Snowberg]

Add two new fields in public_key_signature to track the intended usage of
the signature.  Also add a flag for the revocation pass.  During signature
validation, two verifications can take place for the same signature.  One
to see if it verifies against something on the .blacklist keyring and
the other to see if it verifies against the supplied keyring. The flag
is used to determine which stage the verification is in.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 certs/blacklist.c                     |  3 +++
 crypto/asymmetric_keys/pkcs7_trust.c  | 20 ++++++++++++++++++++
 crypto/asymmetric_keys/pkcs7_verify.c |  4 ++++
 include/crypto/pkcs7.h                |  3 +++
 include/crypto/public_key.h           |  4 ++++
 5 files changed, 34 insertions(+)

diff --git a/certs/blacklist.c b/certs/blacklist.c
index 675dd7a8f07a..dd34e56a6362 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -17,6 +17,7 @@
 #include <linux/uidgid.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
+#include <crypto/public_key.h>
 #include "blacklist.h"
 
 /*
@@ -289,7 +290,9 @@ int is_key_on_revocation_list(struct pkcs7_message *pkcs7)
 {
 	int ret;
 
+	pkcs7_set_usage_flag(pkcs7, PKS_REVOCATION_PASS);
 	ret = pkcs7_validate_trust(pkcs7, blacklist_keyring);
+	pkcs7_clear_usage_flag(pkcs7, PKS_REVOCATION_PASS);
 
 	if (ret == 0)
 		return -EKEYREJECTED;
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c b/crypto/asymmetric_keys/pkcs7_trust.c
index 9a87c34ed173..64d70eb68864 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -131,6 +131,26 @@ static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
 	return 0;
 }
 
+void pkcs7_clear_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage)
+{
+	struct pkcs7_signed_info *sinfo;
+
+	for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
+		if (sinfo->sig)
+			clear_bit(usage, &sinfo->sig->usage_flags);
+	}
+}
+
+void pkcs7_set_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage)
+{
+	struct pkcs7_signed_info *sinfo;
+
+	for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
+		if (sinfo->sig)
+			set_bit(usage, &sinfo->sig->usage_flags);
+	}
+}
+
 /**
  * pkcs7_validate_trust - Validate PKCS#7 trust chain
  * @pkcs7: The PKCS#7 certificate to validate
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 1dc80e68ce96..44b8bd0ad4d8 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -455,6 +455,10 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
 			return ret;
 		}
 		actual_ret = 0;
+		if (sinfo->sig) {
+			sinfo->sig->usage = usage;
+			set_bit(PKS_USAGE_SET, &sinfo->sig->usage_flags);
+		}
 	}
 
 	kleave(" = %d", actual_ret);
diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
index 38ec7f5f9041..6c3c9061b118 100644
--- a/include/crypto/pkcs7.h
+++ b/include/crypto/pkcs7.h
@@ -32,6 +32,9 @@ extern int pkcs7_get_content_data(const struct pkcs7_message *pkcs7,
 extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
 				struct key *trust_keyring);
 
+extern void pkcs7_set_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage);
+extern void pkcs7_clear_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage);
+
 /*
  * pkcs7_verify.c
  */
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index b7f308977c84..394022b5d856 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -49,6 +49,10 @@ struct public_key_signature {
 	const char *pkey_algo;
 	const char *hash_algo;
 	const char *encoding;
+	u32 usage;		/* Intended usage */
+	unsigned long usage_flags;
+#define PKS_USAGE_SET		0
+#define PKS_REVOCATION_PASS	1
 };
 
 extern void public_key_signature_free(struct public_key_signature *sig);
-- 
2.45.0

[RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[Eric Snowberg]

Introduce a new LSM called clavis.  The motivation behind this LSM is to
provide access control for system keys.  The access control list is
contained within a keyring call .clavis.  During boot if the clavis= boot
arg is supplied with a key id contained within any of the current system
keyrings (builtin, secondary, machine, or platform) it shall be used as
the root of trust for validating anything that is added to the ACL list.

The first restriction introduced with this LSM is the ability to enforce
key usage.  The kernel already has a notion of tracking key usage.  This
LSM adds the ability to enforce this usage based on the system owners
configuration.

Each system key may have one or more uses defined within the ACL list.
Until an entry is added to the .clavis keyring, no other system key may
be used for any other purpose.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++++++++++++++
 MAINTAINERS                                   |   7 +
 crypto/asymmetric_keys/signature.c            |   4 +
 include/linux/lsm_count.h                     |   8 +-
 include/linux/lsm_hook_defs.h                 |   2 +
 include/linux/security.h                      |   7 +
 include/uapi/linux/lsm.h                      |   1 +
 security/Kconfig                              |  10 +-
 security/clavis/Makefile                      |   1 +
 security/clavis/clavis.c                      |  26 +++
 security/clavis/clavis.h                      |   4 +
 security/clavis/clavis_keyring.c              |  78 ++++++-
 security/security.c                           |  13 ++
 .../selftests/lsm/lsm_list_modules_test.c     |   3 +
 14 files changed, 346 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/admin-guide/LSM/clavis.rst
 create mode 100644 security/clavis/clavis.c

diff --git a/Documentation/admin-guide/LSM/clavis.rst b/Documentation/admin-guide/LSM/clavis.rst
new file mode 100644
index 000000000000..0e924f638a86
--- /dev/null
+++ b/Documentation/admin-guide/LSM/clavis.rst
@@ -0,0 +1,191 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======
+Clavis
+======
+
+Clavis is a Linux Security Module that provides mandatory access control to
+system kernel keys (i.e. builtin, secondary, machine and platform). These
+restrictions will prohibit keys from being used for validation. Upon boot, the
+Clavis LSM is provided a key id as a boot parameter.  This single key is then
+used as the root of trust for any access control modifications made going
+forward. Access control updates must be signed and validated by this key.
+
+Clavis has its own keyring.  All ACL updates are applied through this keyring.
+The update must be signed by the single root of trust key.
+
+When enabled, all system keys are prohibited from being used until an ACL is
+added for them.
+
+On UEFI platforms, the root of trust key shall survive a kexec. Trying to
+defeat or change it from the command line is not allowed.  The original boot
+parameter is stored in UEFI and will always be referenced following a kexec.
+
+The Clavis LSM contains a system keyring call .clavis.  It contains a single
+asymmetric key that is used to validate anything added to it.  This key can
+be added during boot and must be a preexisting system kernel key.  If the
+``clavis=`` boot parameter is not used, any asymmetric key the user owns
+can be added to enable the LSM.
+
+The only user space components are OpenSSL and the keyctl utility. A new
+key type call ``clavis_key_acl`` is used for ACL updates. Any number of signed
+``clavis_key_acl`` entries may be added to the .clavis keyring. The
+``clavis_key_acl`` contains the subject key identifier along with the allowed
+usage type for the key.
+
+The format is as follows:
+
+.. code-block:: console
+
+  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
+
+The ``clavis_key_acl`` must be S/MIME signed by the sole asymmetric key contained
+within the .clavis keyring.
+
+In the future if new features are added, new key types could be created.
+
+Usage Examples
+==============
+
+How to create a signing key:
+----------------------------
+
+.. code-block:: bash
+
+  cat <<EOF > clavis-lsm.genkey
+  [ req ]
+  default_bits = 4096
+  distinguished_name = req_distinguished_name
+  prompt = no
+  string_mask = utf8only
+  x509_extensions = v3_ca
+  [ req_distinguished_name ]
+  O = TEST
+  CN = Clavis LSM key
+  emailAddress = user@example.com
+  [ v3_ca ]
+  basicConstraints=CA:TRUE
+  subjectKeyIdentifier=hash
+  authorityKeyIdentifier=keyid:always,issuer
+  keyUsage=digitalSignature
+  EOF
+
+  openssl req -new -x509 -utf8 -sha256 -days 3650 -batch \
+        -config clavis-lsm.genkey -outform DER \
+        -out clavis-lsm.x509 -keyout clavis-lsm.priv
+
+How to get the Subject Key Identifier
+-------------------------------------
+
+.. code-block:: bash
+
+  openssl x509 -in ./clavis-lsm.x509 -inform der \
+        -ext subjectKeyIdentifier  -nocert \
+        | tail -n +2 | cut -f2 -d '='| tr -d ':'
+  4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
+
+How to enroll the signing key into the MOK
+------------------------------------------
+
+The key must now be added to the machine or platform keyrings.  This
+indicates the key was added by the system owner. For kernels booted through
+shim, a first-stage UEFI boot loader, a key may be added to the machine keyring
+by doing:
+
+.. code-block:: bash
+
+  mokutil --import ./clavis-lsm.x509
+
+and then rebooting and enrolling the key through MokManager.
+
+How to enable the Clavis LSM
+----------------------------
+
+Add the key id to the ``clavis=`` boot parameter.  With the example above the
+key id is the subject key identifier: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
+
+Add the following boot parameter:
+
+.. code-block:: console
+
+  clavis=4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
+
+After booting there will be a single key contained in the .clavis keyring:
+
+.. code-block:: bash
+
+  keyctl show %:.clavis
+  Keyring
+    254954913 ----swrv      0     0  keyring: .clavis
+    301905375 ---lswrv      0     0   \_ asymmetric: TEST: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
+
+The original ``clavis=`` boot parameter will persist across any kexec. Changing it or
+removing it has no effect.
+
+
+How to sign an entry to be added to the .clavis keyring:
+--------------------------------------------------------
+
+In this example we have 3 keys in the machine keyring.  Our Clavis LSM key, a
+key we want to use for kernel verification and a key we want to use for module
+verification.
+
+.. code-block:: bash
+
+  keyctl show %:.machine
+  Keyring
+    999488265 ---lswrv      0     0  keyring: .machine
+    912608009 ---lswrv      0     0   \_ asymmetric: TEST: Module Key: 17eb8c5bf766364be094c577625213700add9471
+    646229664 ---lswrv      0     0   \_ asymmetric: TEST: Kernel Key: b360d113c848ace3f1e6a80060b43d1206f0487d
+   1073737099 ---lswrv      0     0   \_ asymmetric: TEST: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
+
+To update the .clavis kerying ACL list, first create a file containing the
+key usage type followed by a colon and the key id that we want to allow to
+validate that usage.  In the first example we are saying key
+17eb8c5bf766364be094c577625213700add9471 is allowed to validate kernel modules.
+In the second example we are saying key b360d113c848ace3f1e6a80060b43d1206f0487d
+is allowed to validate signed kernels.
+
+.. code-block:: bash
+
+  echo "00:17eb8c5bf766364be094c577625213700add9471" > module-acl.txt
+  echo "02:b360d113c848ace3f1e6a80060b43d1206f0487d" > kernel-acl.txt
+
+Now both these files must be signed by the key contained in the .clavis keyring:
+
+.. code-block:: bash
+
+  openssl smime -sign -signer clavis-lsm.x509 -inkey clavis-lsm.priv -in module-acl.txt \
+        -out module-acl.pkcs7 -binary -outform DER -nodetach -noattr
+
+  openssl smime -sign -signer clavis-lsm.x509 -inkey clavis-lsm.priv -in kernel-acl.txt \
+        -out kernel-acl.pkcs7 -binary -outform DER -nodetach -noattr
+
+Afterwards the ACL list in the clavis keyring can be updated:
+
+.. code-block:: bash
+
+  keyctl padd clavis_key_acl "" %:.clavis < module-acl.pkcs7
+  keyctl padd clavis_key_acl "" %:.clavis < kernel-acl.pkcs7
+
+  keyctl show %:.clavis
+
+  Keyring
+    254954913 ----swrv      0     0  keyring: .clavis
+    301905375 ---lswrv      0     0   \_ asymmetric: TEST: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
+   1013065475 --alswrv      0     0   \_ clavis_key_acl: 02:b360d113c848ace3f1e6a80060b43d1206f0487d
+    445581284 --alswrv      0     0   \_ clavis_key_acl: 00:17eb8c5bf766364be094c577625213700add9471
+
+Now the 17eb8c5bf766364be094c577625213700add9471 key can be used for
+validating kernel modules and the b360d113c848ace3f1e6a80060b43d1206f0487d
+key can be used to validate signed kernels.
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ad507f49324..748ba3f1143e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5567,6 +5567,13 @@ F:	scripts/Makefile.clang
 F:	scripts/clang-tools/
 K:	\b(?i:clang|llvm)\b
 
+CLAVIS LINUX SECURITY MODULE
+M:	Eric Snowberg <eric.snowberg@oracle.com>
+L:	linux-security-module@vger.kernel.org
+S:	Maintained
+F:	Documentation/admin-guide/LSM/clavis.rst
+F:	security/clavis
+
 CLK API
 M:	Russell King <linux@armlinux.org.uk>
 L:	linux-clk@vger.kernel.org
diff --git a/crypto/asymmetric_keys/signature.c b/crypto/asymmetric_keys/signature.c
index 2deff81f8af5..7e3a78650a93 100644
--- a/crypto/asymmetric_keys/signature.c
+++ b/crypto/asymmetric_keys/signature.c
@@ -13,6 +13,7 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include <linux/keyctl.h>
+#include <linux/security.h>
 #include <crypto/public_key.h>
 #include <keys/user-type.h>
 #include "asymmetric_keys.h"
@@ -153,6 +154,9 @@ int verify_signature(const struct key *key,
 
 	ret = subtype->verify_signature(key, sig);
 
+	if (!ret)
+		ret = security_key_verify_signature(key, sig);
+
 	pr_devel("<==%s() = %d\n", __func__, ret);
 	return ret;
 }
diff --git a/include/linux/lsm_count.h b/include/linux/lsm_count.h
index 16eb49761b25..146aba3993d9 100644
--- a/include/linux/lsm_count.h
+++ b/include/linux/lsm_count.h
@@ -102,6 +102,11 @@
 #define IPE_ENABLED
 #endif
 
+#if IS_ENABLED(CONFIG_SECURITY_CLAVIS)
+#define CLAVIS_ENABLED 1,
+#else
+#define CLAVIS_ENABLED
+#endif
 /*
  *  There is a trailing comma that we need to be accounted for. This is done by
  *  using a skipped argument in __COUNT_LSMS
@@ -124,7 +129,8 @@
 		LANDLOCK_ENABLED	\
 		IMA_ENABLED		\
 		EVM_ENABLED		\
-		IPE_ENABLED)
+		IPE_ENABLED		\
+		CLAVIS_ENABLED)
 
 #else
 
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 9eca013aa5e1..a405122a4657 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -410,6 +410,8 @@ LSM_HOOK(int, 0, key_getsecurity, struct key *key, char **buffer)
 LSM_HOOK(void, LSM_RET_VOID, key_post_create_or_update, struct key *keyring,
 	 struct key *key, const void *payload, size_t payload_len,
 	 unsigned long flags, bool create)
+LSM_HOOK(int, 0, key_verify_signature, const struct key *key,
+	 const struct public_key_signature *sig)
 #endif /* CONFIG_KEYS */
 
 #ifdef CONFIG_AUDIT
diff --git a/include/linux/security.h b/include/linux/security.h
index 2ec8f3014757..4439be172a51 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -63,6 +63,7 @@ enum fs_value_type;
 struct watch;
 struct watch_notification;
 struct lsm_ctx;
+struct public_key_signature;
 
 /* Default (no) options for the capable function */
 #define CAP_OPT_NONE 0x0
@@ -2053,6 +2054,7 @@ void security_key_post_create_or_update(struct key *keyring, struct key *key,
 					const void *payload, size_t payload_len,
 					unsigned long flags, bool create);
 
+int security_key_verify_signature(const struct key *key, const struct public_key_signature *sig);
 #else
 
 static inline int security_key_alloc(struct key *key,
@@ -2087,6 +2089,11 @@ static inline void security_key_post_create_or_update(struct key *keyring,
 						      bool create)
 { }
 
+static inline int security_key_verify_signature(const struct key *key,
+						const struct public_key_signature *sig)
+{
+	return 0;
+}
 #endif
 #endif /* CONFIG_KEYS */
 
diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
index 938593dfd5da..a2ef13c71143 100644
--- a/include/uapi/linux/lsm.h
+++ b/include/uapi/linux/lsm.h
@@ -65,6 +65,7 @@ struct lsm_ctx {
 #define LSM_ID_IMA		111
 #define LSM_ID_EVM		112
 #define LSM_ID_IPE		113
+#define LSM_ID_CLAVIS		114
 
 /*
  * LSM_ATTR_XXX definitions identify different LSM attributes
diff --git a/security/Kconfig b/security/Kconfig
index 714ec08dda96..90355ddec5c0 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -265,11 +265,11 @@ endchoice
 
 config LSM
 	string "Ordered list of enabled LSMs"
-	default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,ipe,bpf" if DEFAULT_SECURITY_SMACK
-	default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,ipe,bpf" if DEFAULT_SECURITY_APPARMOR
-	default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,ipe,bpf" if DEFAULT_SECURITY_TOMOYO
-	default "landlock,lockdown,yama,loadpin,safesetid,ipe,bpf" if DEFAULT_SECURITY_DAC
-	default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf"
+	default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,ipe,bpf,clavis" if DEFAULT_SECURITY_SMACK
+	default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,ipe,bpf,clavis" if DEFAULT_SECURITY_APPARMOR
+	default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,ipe,bpf,clavis" if DEFAULT_SECURITY_TOMOYO
+	default "landlock,lockdown,yama,loadpin,safesetid,ipe,bpf,clavis" if DEFAULT_SECURITY_DAC
+	default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf,clavis"
 	help
 	  A comma-separated list of LSMs, in initialization order.
 	  Any LSMs left off this list, except for those with order
diff --git a/security/clavis/Makefile b/security/clavis/Makefile
index 16c451f45f37..a3430dd6bdf9 100644
--- a/security/clavis/Makefile
+++ b/security/clavis/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
+obj-$(CONFIG_SECURITY_CLAVIS) += clavis.o
diff --git a/security/clavis/clavis.c b/security/clavis/clavis.c
new file mode 100644
index 000000000000..21ade9e625dc
--- /dev/null
+++ b/security/clavis/clavis.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+#include <linux/lsm_hooks.h>
+#include <uapi/linux/lsm.h>
+#include "clavis.h"
+
+static struct security_hook_list clavis_hooks[] __ro_after_init = {
+	LSM_HOOK_INIT(key_verify_signature, clavis_sig_verify),
+};
+
+const struct lsm_id clavis_lsmid = {
+	.name = "clavis",
+	.id = LSM_ID_CLAVIS,
+};
+
+static int __init clavis_lsm_init(void)
+{
+	clavis_keyring_init();
+	security_add_hooks(clavis_hooks, ARRAY_SIZE(clavis_hooks), &clavis_lsmid);
+	return 0;
+};
+
+DEFINE_LSM(clavis) = {
+	.name = "clavis",
+	.init = clavis_lsm_init,
+};
diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
index 92f77a1939ad..b77e4ec8edbe 100644
--- a/security/clavis/clavis.h
+++ b/security/clavis/clavis.h
@@ -3,6 +3,8 @@
 #define _SECURITY_CLAVIS_H_
 #include <keys/asymmetric-type.h>
 
+struct public_key_signature;
+
 /* Max length for the asymmetric key id contained on the boot param */
 #define CLAVIS_BIN_KID_MAX   32
 #define CLAVIS_ASCII_KID_MAX 64
@@ -20,4 +22,6 @@ const char __initconst *const clavis_module_acl[] = {
 extern const char __initconst *const clavis_module_acl[];
 #endif
 
+int __init clavis_keyring_init(void);
+int clavis_sig_verify(const struct key *key, const struct public_key_signature *sig);
 #endif /* _SECURITY_CLAVIS_H_ */
diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
index 2a18d0e77189..1e1fbb54f6be 100644
--- a/security/clavis/clavis_keyring.c
+++ b/security/clavis/clavis_keyring.c
@@ -284,7 +284,7 @@ static void clavis_add_acl(const char *const *skid_list, struct key *keyring)
 	}
 }
 
-static int __init clavis_keyring_init(void)
+int __init clavis_keyring_init(void)
 {
 	struct key_restriction *restriction;
 
@@ -306,10 +306,82 @@ static int __init clavis_keyring_init(void)
 
 void __init late_init_clavis_setup(void)
 {
-	clavis_keyring_init();
-
 	if (!clavis_boot_akid)
 		return;
 
 	system_key_link(clavis_keyring, clavis_boot_akid);
 }
+
+int clavis_sig_verify(const struct key *key, const struct public_key_signature *sig)
+{
+	const struct asymmetric_key_ids *kids = asymmetric_key_ids(key);
+	const struct asymmetric_key_subtype *subtype;
+	const struct asymmetric_key_id *newkid;
+	char *buf_ptr, *ptr;
+	key_ref_t ref;
+	int i, buf_len;
+
+	if (!clavis_acl_enforced())
+		return 0;
+	if (key->type != &key_type_asymmetric)
+		return -EKEYREJECTED;
+	subtype = asymmetric_key_subtype(key);
+	if (!subtype || !key->payload.data[0])
+		return -EKEYREJECTED;
+	if (!subtype->verify_signature)
+		return -EKEYREJECTED;
+
+	/* Allow sig validation when not using a system keyring */
+	if (!test_bit(PKS_USAGE_SET, &sig->usage_flags))
+		return 0;
+
+	/* The previous sig validation is enough to get on the clavis keyring */
+	if (sig->usage == VERIFYING_CLAVIS_SIGNATURE)
+		return 0;
+
+	if (test_bit(PKS_REVOCATION_PASS, &sig->usage_flags))
+		return 0;
+
+	for (i = 0, buf_len = 0; i < 3; i++) {
+		if (kids->id[i]) {
+			newkid = (struct asymmetric_key_id *)kids->id[i];
+			if (newkid->len > buf_len)
+				buf_len = newkid->len;
+		}
+	}
+
+	if (!buf_len)
+		return -EKEYREJECTED;
+
+	/* Allocate enough space for the conversion to ascii plus the header. */
+	buf_ptr = kmalloc(buf_len * 2 + 4, GFP_KERNEL | __GFP_ZERO);
+
+	if (!buf_ptr)
+		return -ENOMEM;
+
+	for (i = 0; i < 3; i++) {
+		if (kids->id[i]) {
+			newkid = (struct asymmetric_key_id *)kids->id[i];
+			if (!newkid->len)
+				continue;
+
+			ptr = buf_ptr;
+			ptr = bin2hex(ptr, &sig->usage, 1);
+			*ptr++ = ':';
+			ptr = bin2hex(ptr, newkid->data, newkid->len);
+			*ptr = 0;
+			ref = keyring_search(make_key_ref(clavis_keyring_get(), true),
+					     &clavis_key_acl, buf_ptr, false);
+
+			if (!IS_ERR(ref))
+				break;
+		}
+	}
+
+	kfree(buf_ptr);
+
+	if (IS_ERR(ref))
+		return -EKEYREJECTED;
+
+	return 0;
+}
diff --git a/security/security.c b/security/security.c
index c5981e558bc2..097f8cedcd36 100644
--- a/security/security.c
+++ b/security/security.c
@@ -5522,6 +5522,19 @@ void security_key_post_create_or_update(struct key *keyring, struct key *key,
 	call_void_hook(key_post_create_or_update, keyring, key, payload,
 		       payload_len, flags, create);
 }
+
+/**
+ * security_key_verify_signature - verify signature
+ * @key: key
+ * @sig: signature
+ *
+ * See whether signature verification is allowed based on the ACL for
+ * key usage.
+ */
+int security_key_verify_signature(const struct key *key, const struct public_key_signature *sig)
+{
+	return call_int_hook(key_verify_signature, key, sig);
+}
 #endif	/* CONFIG_KEYS */
 
 #ifdef CONFIG_AUDIT
diff --git a/tools/testing/selftests/lsm/lsm_list_modules_test.c b/tools/testing/selftests/lsm/lsm_list_modules_test.c
index 1cc8a977c711..cf292f976ac4 100644
--- a/tools/testing/selftests/lsm/lsm_list_modules_test.c
+++ b/tools/testing/selftests/lsm/lsm_list_modules_test.c
@@ -131,6 +131,9 @@ TEST(correct_lsm_list_modules)
 		case LSM_ID_IPE:
 			name = "ipe";
 			break;
+		case LSM_ID_CLAVIS:
+			name = "clavis";
+			break;
 		default:
 			name = "INVALID";
 			break;
-- 
2.45.0

[RFC PATCH v3 09/13] clavis: Allow user to define acl at build time

[Eric Snowberg]

Add a new Kconfig called Security_CLAVIS_ACL_LIST. If set, this option
should be the file name of a list of clavis ACL entries. This will be
included into a C wrapper to incorporate the acl list into the kernel.
The file contents must be in the following format: <two digit key usage
number>:<subject key id>. If more than one entry is added, add a carriage
return after each entry.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 security/clavis/.gitignore           |  1 +
 security/clavis/Kconfig              | 10 ++++++++++
 security/clavis/Makefile             | 16 ++++++++++++++++
 security/clavis/clavis.h             |  2 ++
 security/clavis/clavis_builtin_acl.c |  7 +++++++
 security/clavis/clavis_keyring.c     |  1 +
 6 files changed, 37 insertions(+)
 create mode 100644 security/clavis/.gitignore
 create mode 100644 security/clavis/clavis_builtin_acl.c

diff --git a/security/clavis/.gitignore b/security/clavis/.gitignore
new file mode 100644
index 000000000000..c1b60bee049e
--- /dev/null
+++ b/security/clavis/.gitignore
@@ -0,0 +1 @@
+/builtin_acl
diff --git a/security/clavis/Kconfig b/security/clavis/Kconfig
index 04f7565f2e2b..b702311ec905 100644
--- a/security/clavis/Kconfig
+++ b/security/clavis/Kconfig
@@ -9,3 +9,13 @@ config SECURITY_CLAVIS
 	  keyrings (builtin, secondary, or platform).  One way to add this key
 	  is during boot by passing in the asymmetric key id within the "clavis=" boot
 	  param.  This keyring is required by the Clavis LSM.
+
+config SECURITY_CLAVIS_ACL_LIST
+	string "Clavis ACL list to preload into the clavis keyring"
+	depends on SECURITY_CLAVIS
+	help
+	  If set, this option should be the file name of a list of clavis ACL
+	  entries. This will be included into a C wrapper to incorporate the
+	  acl list into the kernel. The file contents must be in the following
+	  format: <two digit key usage number>:<subject key id>.  If more than
+	  one entry is added, add a carriage return after each entry.
diff --git a/security/clavis/Makefile b/security/clavis/Makefile
index a3430dd6bdf9..082e6d3c0934 100644
--- a/security/clavis/Makefile
+++ b/security/clavis/Makefile
@@ -2,3 +2,19 @@
 
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis.o
+obj-$(CONFIG_SECURITY_CLAVIS) += clavis_builtin_acl.o
+
+ifeq ($(CONFIG_SECURITY_CLAVIS_ACL_LIST),)
+quiet_cmd_make_builtin_acl = GEN     $@
+      cmd_make_builtin_acl = \
+	echo > $@
+else
+quiet_cmd_make_builtin_acl = GEN     $@
+      cmd_make_builtin_acl = \
+	sed 's/^[ \t]*//; s/.*/"&",/' $< | tr '[:upper:]' '[:lower:]' > $@
+endif
+
+$(obj)/builtin_acl: $(CONFIG_SECURITY_CLAVIS_ACL_LIST) FORCE
+	$(call if_changed,make_builtin_acl)
+
+$(obj)/clavis_builtin_acl.o: $(obj)/builtin_acl
diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
index b77e4ec8edbe..7099a517b111 100644
--- a/security/clavis/clavis.h
+++ b/security/clavis/clavis.h
@@ -14,6 +14,8 @@ struct asymmetric_setup_kid {
 	unsigned char data[CLAVIS_BIN_KID_MAX];
 };
 
+extern const char __initconst *const clavis_builtin_acl_list[];
+
 #ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
 const char __initconst *const clavis_module_acl[] = {
 	 NULL
diff --git a/security/clavis/clavis_builtin_acl.c b/security/clavis/clavis_builtin_acl.c
new file mode 100644
index 000000000000..c98b6df05413
--- /dev/null
+++ b/security/clavis/clavis_builtin_acl.c
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "clavis.h"
+
+const char __initconst *const clavis_builtin_acl_list[] = {
+#include "builtin_acl"
+	NULL
+};
diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
index 1e1fbb54f6be..a4a95a931b50 100644
--- a/security/clavis/clavis_keyring.c
+++ b/security/clavis/clavis_keyring.c
@@ -300,6 +300,7 @@ int __init clavis_keyring_init(void)
 		panic("Can't allocate clavis keyring\n");
 
 	clavis_add_acl(clavis_module_acl, clavis_keyring);
+	clavis_add_acl(clavis_builtin_acl_list, clavis_keyring);
 
 	return 0;
 }
-- 
2.45.0

[RFC PATCH v3 10/13] efi: Make clavis boot param persist across kexec

[Eric Snowberg]

Add the ability for the clavis boot param to persist across kexec.  This is
done by creating a RT variable before ExitBootServices is called. The new
variable is called Clavis with a new GUID
193ccef6-348b-4f1f-a81b-0ea4b899dbf2.  This variable does not have NVRAM
set, signifying it was created during the Boot Services phase.  This
variable will persist across a kexec, however it will not persist across
a power on reset.  This same type of functionality is currently used
within EFI shim to mirror MOK variables into the kernel.  It is being used
here so the clavis boot param can not be changed via kexec.  If a different
clavis boot param is used, the one stored in the RT variable will be used
instead. Enforcement of which boot param to use will be done in a follow
on patch.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 drivers/firmware/efi/Kconfig                  | 12 +++++++
 drivers/firmware/efi/libstub/Makefile         |  1 +
 drivers/firmware/efi/libstub/clavis.c         | 33 +++++++++++++++++++
 .../firmware/efi/libstub/efi-stub-helper.c    |  2 ++
 drivers/firmware/efi/libstub/efi-stub.c       |  2 ++
 drivers/firmware/efi/libstub/efistub.h        |  8 +++++
 drivers/firmware/efi/libstub/x86-stub.c       |  2 ++
 include/linux/efi.h                           |  1 +
 8 files changed, 61 insertions(+)
 create mode 100644 drivers/firmware/efi/libstub/clavis.c

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 72f2537d90ca..8dcb5326d05d 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -186,6 +186,18 @@ config RESET_ATTACK_MITIGATION
 	  have been evicted, since otherwise it will trigger even on clean
 	  reboots.
 
+config EARLY_CLAVIS
+	bool "Early clavis"
+	depends on EFI_STUB
+	help
+	  Allow the clavis boot param to persist across kexec. This will create a
+	  variable called Clavis with a 193ccef6-348b-4f1f-a81b-0ea4b899dbf2 GUID.
+	  This variable does not have NVRAM set, signifying it was created during
+	  the Boot Services phase.  This variable will persist across a kexec,
+	  however it will not persist across a power on reset. During kexec, if
+	  a different clavis boot param is used, the one stored in the RT variable
+	  will be used instead.
+
 config EFI_RCI2_TABLE
 	bool "EFI Runtime Configuration Interface Table Version 2 Support"
 	depends on X86 || COMPILE_TEST
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index ed4e8ddbe76a..b5243543ccc9 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -86,6 +86,7 @@ lib-$(CONFIG_X86)		+= x86-stub.o smbios.o
 lib-$(CONFIG_X86_64)		+= x86-5lvl.o
 lib-$(CONFIG_RISCV)		+= kaslr.o riscv.o riscv-stub.o
 lib-$(CONFIG_LOONGARCH)		+= loongarch.o loongarch-stub.o
+lib-$(CONFIG_EARLY_CLAVIS)	+= clavis.o
 
 CFLAGS_arm32-stub.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 
diff --git a/drivers/firmware/efi/libstub/clavis.c b/drivers/firmware/efi/libstub/clavis.c
new file mode 100644
index 000000000000..3a715e87a13a
--- /dev/null
+++ b/drivers/firmware/efi/libstub/clavis.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/efi.h>
+#include <asm/efi.h>
+#include "efistub.h"
+
+#define MAX_PARAM_LENGTH 64
+static const efi_char16_t clavis_param_name[] = L"Clavis";
+static const efi_guid_t clavis_guid = LINUX_EFI_CLAVIS_GUID;
+static unsigned char param_data[MAX_PARAM_LENGTH];
+static size_t param_len;
+
+void efi_parse_clavis(char *option)
+{
+	if (!option)
+		return;
+
+	param_len = strnlen(option, MAX_PARAM_LENGTH);
+	memcpy(param_data, option, param_len);
+}
+
+void efi_setup_clavis(void)
+{
+	efi_status_t error;
+
+	if (param_len) {
+		error = set_efi_var(clavis_param_name, &clavis_guid,
+				    EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
+				    param_len, &param_data);
+	}
+
+	if (error)
+		efi_err("Failed to set Clavis\n");
+}
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index de659f6a815f..3c45eaec325d 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -100,6 +100,8 @@ efi_status_t efi_parse_options(char const *cmdline)
 		} else if (!strcmp(param, "video") &&
 			   val && strstarts(val, "efifb:")) {
 			efi_parse_option_graphics(val + strlen("efifb:"));
+		} else if (!strcmp(param, "clavis") && val) {
+			efi_parse_clavis(val);
 		}
 	}
 	efi_bs_call(free_pool, buf);
diff --git a/drivers/firmware/efi/libstub/efi-stub.c b/drivers/firmware/efi/libstub/efi-stub.c
index 958a680e0660..c15cd0d9e71f 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -183,6 +183,8 @@ efi_status_t efi_stub_common(efi_handle_t handle,
 
 	install_memreserve_table();
 
+	efi_setup_clavis();
+
 	status = efi_boot_kernel(handle, image, image_addr, cmdline_ptr);
 
 	free_screen_info(si);
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 685098f9626f..ddd51d7f19c3 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -1142,6 +1142,14 @@ static inline void
 efi_enable_reset_attack_mitigation(void) { }
 #endif
 
+#ifdef CONFIG_EARLY_CLAVIS
+void efi_parse_clavis(char *option);
+void efi_setup_clavis(void);
+#else
+static inline void efi_parse_clavis(char *option) { }
+static inline void efi_setup_clavis(void) { }
+#endif
+
 void efi_retrieve_eventlog(void);
 
 struct screen_info *alloc_screen_info(void);
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index f8e465da344d..facec319d978 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -1044,6 +1044,8 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
 
 	setup_unaccepted_memory();
 
+	efi_setup_clavis();
+
 	status = exit_boot(boot_params, handle);
 	if (status != EFI_SUCCESS) {
 		efi_err("exit_boot() failed!\n");
diff --git a/include/linux/efi.h b/include/linux/efi.h
index e28d88066033..a6ab5d30d25c 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -423,6 +423,7 @@ void efi_native_runtime_setup(void);
 #define LINUX_EFI_UNACCEPTED_MEM_TABLE_GUID	EFI_GUID(0xd5d1de3c, 0x105c, 0x44f9,  0x9e, 0xa9, 0xbc, 0xef, 0x98, 0x12, 0x00, 0x31)
 
 #define RISCV_EFI_BOOT_PROTOCOL_GUID		EFI_GUID(0xccd15fec, 0x6f73, 0x4eec,  0x83, 0x95, 0x3e, 0x69, 0xe4, 0xb9, 0x40, 0xbf)
+#define LINUX_EFI_CLAVIS_GUID			EFI_GUID(0x193ccef6, 0x348b, 0x4f1f,  0xa8, 0x1b, 0x0e, 0xa4, 0xb8, 0x99, 0xdb, 0xf2)
 
 /*
  * This GUID may be installed onto the kernel image's handle as a NULL protocol
-- 
2.45.0

[RFC PATCH v3 11/13] clavis: Prevent boot param change during kexec

[Eric Snowberg]

If found, use the new Clavis EFI RT variable to validate the clavis boot
param didn't change during a reboot.  If the boot param is different or
missing, use the one stored in EFI instead.  This will prevent a pivot
in the root of trust for the upcoming Clavis LSM. If CONFIG_EARLY_CLAVIS
is not enabled, the Clavis EFI RT variable will never be set and
therefore not used.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 security/clavis/Makefile         |  4 +++
 security/clavis/clavis.h         |  9 ++++++
 security/clavis/clavis_efi.c     | 50 ++++++++++++++++++++++++++++++++
 security/clavis/clavis_keyring.c | 11 ++++++-
 4 files changed, 73 insertions(+), 1 deletion(-)
 create mode 100644 security/clavis/clavis_efi.c

diff --git a/security/clavis/Makefile b/security/clavis/Makefile
index 082e6d3c0934..af68a44a0cb4 100644
--- a/security/clavis/Makefile
+++ b/security/clavis/Makefile
@@ -18,3 +18,7 @@ $(obj)/builtin_acl: $(CONFIG_SECURITY_CLAVIS_ACL_LIST) FORCE
 	$(call if_changed,make_builtin_acl)
 
 $(obj)/clavis_builtin_acl.o: $(obj)/builtin_acl
+
+ifeq ($(CONFIG_EFI),y)
+obj-$(CONFIG_SECURITY_CLAVIS) += clavis_efi.o
+endif
diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
index 7099a517b111..6f68b560311e 100644
--- a/security/clavis/clavis.h
+++ b/security/clavis/clavis.h
@@ -24,6 +24,15 @@ const char __initconst *const clavis_module_acl[] = {
 extern const char __initconst *const clavis_module_acl[];
 #endif
 
+#ifdef CONFIG_EFI
+int clavis_efi_param(struct asymmetric_key_id *kid, int len);
+#else
+static inline int __init clavis_efi_param(struct asymmetric_key_id *kid, int len)
+{
+	return -EINVAL;
+}
+#endif
+
 int __init clavis_keyring_init(void);
 int clavis_sig_verify(const struct key *key, const struct public_key_signature *sig);
 #endif /* _SECURITY_CLAVIS_H_ */
diff --git a/security/clavis/clavis_efi.c b/security/clavis/clavis_efi.c
new file mode 100644
index 000000000000..0d9c392f4697
--- /dev/null
+++ b/security/clavis/clavis_efi.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <keys/asymmetric-type.h>
+#include <linux/efi.h>
+#include "clavis.h"
+
+static efi_char16_t clavis_param_name[] = L"Clavis";
+static efi_guid_t clavis_guid = LINUX_EFI_CLAVIS_GUID;
+
+int __init clavis_efi_param(struct asymmetric_key_id *kid, int len)
+{
+	unsigned char buf[64];
+	unsigned long ascii_len = sizeof(buf);
+	efi_status_t error;
+	int hex_len;
+	u32 attr;
+
+	if (!efi_enabled(EFI_BOOT)) {
+		pr_debug("efi_enabled(EFI_BOOT) not set");
+		return -EPERM;
+	}
+
+	if (!efi_enabled(EFI_RUNTIME_SERVICES)) {
+		pr_debug("%s : EFI runtime services are not enabled\n", __func__);
+		return -EPERM;
+	}
+
+	error = efi.get_variable(clavis_param_name, &clavis_guid, &attr, &ascii_len, &buf);
+
+	if (error) {
+		pr_debug("Error reading clavis parm or not found\n");
+		return -EINVAL;
+	}
+
+	if (attr & EFI_VARIABLE_NON_VOLATILE)  {
+		pr_debug("Error: NV access set\n");
+		return -EINVAL;
+	} else if (ascii_len > 0) {
+		hex_len = ascii_len / 2;
+
+		if (hex_len > len) {
+			pr_debug("invalid length\n");
+			return -EINVAL;
+		}
+		kid->len = hex_len;
+		return hex2bin(kid->data, buf, kid->len);
+	}
+
+	pr_debug("Error: invalid size\n");
+	return -EINVAL;
+}
diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
index a4a95a931b50..81bfc3ed02a3 100644
--- a/security/clavis/clavis_keyring.c
+++ b/security/clavis/clavis_keyring.c
@@ -307,9 +307,18 @@ int __init clavis_keyring_init(void)
 
 void __init late_init_clavis_setup(void)
 {
-	if (!clavis_boot_akid)
+	struct asymmetric_setup_kid efi_keyid;
+	struct asymmetric_key_id *keyid = &efi_keyid.id;
+	int error;
+
+	error = clavis_efi_param(keyid, ARRAY_SIZE(efi_keyid.data));
+
+	if (error && !clavis_boot_akid)
 		return;
 
+	if (error)
+		keyid = clavis_boot_akid;
+
 	system_key_link(clavis_keyring, clavis_boot_akid);
 }
 
-- 
2.45.0

[RFC PATCH v3 12/13] clavis: Add function redirection for Kunit support

[Eric Snowberg]

In preparation for Kunit support within Clavis, add function redirection
for some of the static functions.  Also Add KUNIT_STATIC_STUB_REDIRECT
to a few functions that will be redirected in the future.  This should
have no functional change.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 security/clavis/clavis_keyring.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
index 81bfc3ed02a3..339af707b612 100644
--- a/security/clavis/clavis_keyring.c
+++ b/security/clavis/clavis_keyring.c
@@ -8,6 +8,7 @@
 #include <keys/system_keyring.h>
 #include <keys/user-type.h>
 #include <crypto/pkcs7.h>
+#include <kunit/static_stub.h>
 #include "clavis.h"
 
 static struct key *clavis_keyring;
@@ -46,6 +47,9 @@ static int pkcs7_preparse_content(void *ctx, const void *data, size_t len, size_
 	return ret;
 }
 
+int (* const pkcs7_preparse_content_fn_ptr)(void *ctx, const void *data, size_t len,
+					    size_t asn1hdrlen) = pkcs7_preparse_content;
+
 static void key_acl_free_preparse(struct key_preparsed_payload *prep)
 {
 	kfree(prep->description);
@@ -54,16 +58,24 @@ static void key_acl_free_preparse(struct key_preparsed_payload *prep)
 
 static struct key *clavis_keyring_get(void)
 {
+	KUNIT_STATIC_STUB_REDIRECT(clavis_keyring_get);
 	return clavis_keyring;
 }
 
+struct key * (* const clavis_keyring_get_fn_ptr)(void) = clavis_keyring_get;
+
 static bool clavis_acl_enforced(void)
 {
+	KUNIT_STATIC_STUB_REDIRECT(clavis_acl_enforced);
 	return clavis_enforced;
 }
 
+bool (* const clavis_acl_enforced_fn_ptr)(void) = clavis_acl_enforced;
+
 static int key_acl_preparse(struct key_preparsed_payload *prep)
 {
+	KUNIT_STATIC_STUB_REDIRECT(key_acl_preparse, prep);
+
 	/*
 	 * Only allow the description to be set via the pkcs7 data contents.
 	 * The exception to this rule is if the entry was builtin, it will have
@@ -79,6 +91,8 @@ static int key_acl_preparse(struct key_preparsed_payload *prep)
 				      prep);
 }
 
+int (* const key_acl_preparse_fn_ptr)(struct key_preparsed_payload *prep) = key_acl_preparse;
+
 static int key_acl_instantiate(struct key *key, struct key_preparsed_payload *prep)
 {
 	/*
@@ -225,6 +239,10 @@ static struct asymmetric_key_id *clavis_parse_boot_param(char *kid, struct asymm
 	return akid;
 }
 
+struct asymmetric_key_id *
+	(* const parse_boot_param_fn_ptr)(char *kid, struct asymmetric_key_id *akid,
+					  int akid_max_len) = clavis_parse_boot_param;
+
 static int __init clavis_param(char *kid)
 {
 	clavis_boot_akid = clavis_parse_boot_param(kid, &clavis_setup_akid.id,
@@ -247,6 +265,10 @@ static struct key *clavis_keyring_alloc(const char *desc, struct key_restriction
 	return keyring;
 }
 
+struct key *
+	(* const keyring_alloc_fn_ptr)(const char *desc, struct key_restriction *restriction) =
+				       clavis_keyring_alloc;
+
 static struct key_restriction *clavis_restriction_alloc(key_restrict_link_func_t check_func)
 {
 	struct key_restriction *restriction;
@@ -259,6 +281,10 @@ static struct key_restriction *clavis_restriction_alloc(key_restrict_link_func_t
 	return restriction;
 }
 
+struct key_restriction *
+	(* const restriction_alloc_fn_ptr)(key_restrict_link_func_t
+					   check_func) = clavis_restriction_alloc;
+
 static void clavis_add_acl(const char *const *skid_list, struct key *keyring)
 {
 	const char *const *acl;
@@ -284,6 +310,9 @@ static void clavis_add_acl(const char *const *skid_list, struct key *keyring)
 	}
 }
 
+void (* const clavis_add_acl_fn_ptr)(const char *const *skid_list,
+				     struct key *keyring) = clavis_add_acl;
+
 int __init clavis_keyring_init(void)
 {
 	struct key_restriction *restriction;
-- 
2.45.0

[RFC PATCH v3 13/13] clavis: Kunit support

[Eric Snowberg]

Add Kunit coverage to Clavis.

The Makefile will generate multiple test vectors.  All test vectors will
end up in the x509.h, acl.h or signed_data.h file.

The clavis test vectors (ctv) include:

	6 different x509 certs. One for each of the different key usage types.
	This will be loaded into the machine_kunit keyring.
		ctv_0[x]_x509

	1 x509 cert that will be used for revocations:
		ctv_rev_x509

	6 different Clavis ACL's.  One for each usage type:
		ctv_0[x]_x509_acl

	2 different Clavis keys ctv_ca0_x509 and ctv_ca1_x509.

	12 different PCKS7 signed Clavis ACLs.
	   6 signed by ctv_ca0:
	     ctv_ca0_0[x]_pkcs7

	   6 signed by ctv_ca1
	     ctv_ca1_0[x]_pkcs7

	1 signed module (with random data) signed by a key in the module ACL:
		ctv_module_ca0_signed

	1 signed module (with random data) signed by a revoked key:
		ctv_module_rev_signed

	1 Unspecified data that is PKCS7 signed the key unspecified data ACL:
		ctv_data_05_signed

The tests can be enabled through a new Kconfig: SECURITY_CLAVIS_KUNIT_TEST.

Run all KUnit tests for Clavis with:
	  ./tools/testing/kunit/kunit.py run --kunitconfig security/clavis

The only areas missing are stubbing out EFI and system_key_link.
Everything else should be covered with this patch.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 security/clavis/.gitignore    |   1 +
 security/clavis/.kunitconfig  |   4 +
 security/clavis/Kconfig       |  16 +
 security/clavis/Makefile      | 132 ++++++++
 security/clavis/clavis.h      |  24 ++
 security/clavis/clavis_test.c | 566 ++++++++++++++++++++++++++++++++++
 6 files changed, 743 insertions(+)
 create mode 100644 security/clavis/.kunitconfig
 create mode 100644 security/clavis/clavis_test.c

diff --git a/security/clavis/.gitignore b/security/clavis/.gitignore
index c1b60bee049e..2c160c45fc53 100644
--- a/security/clavis/.gitignore
+++ b/security/clavis/.gitignore
@@ -1 +1,2 @@
 /builtin_acl
+/sign-file*
diff --git a/security/clavis/.kunitconfig b/security/clavis/.kunitconfig
new file mode 100644
index 000000000000..c3d2e0eccb06
--- /dev/null
+++ b/security/clavis/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_SECURITY=y
+CONFIG_SECURITY_CLAVIS=y
+CONFIG_SECURITY_CLAVIS_KUNIT_TEST=y
diff --git a/security/clavis/Kconfig b/security/clavis/Kconfig
index b702311ec905..32cd9799cac9 100644
--- a/security/clavis/Kconfig
+++ b/security/clavis/Kconfig
@@ -19,3 +19,19 @@ config SECURITY_CLAVIS_ACL_LIST
 	  acl list into the kernel. The file contents must be in the following
 	  format: <two digit key usage number>:<subject key id>.  If more than
 	  one entry is added, add a carriage return after each entry.
+
+config SECURITY_CLAVIS_KUNIT_TEST
+	bool "KUnit tests for Clavis" if !KUNIT_ALL_TESTS
+	depends on SECURITY_CLAVIS && KUNIT
+	default KUNIT_ALL_TESTS
+	select SYSTEM_BLACKLIST_KEYRING
+	select SYSTEM_REVOCATION_LIST
+	help
+	  Build KUnit tests for Clavis.
+
+	  See the KUnit documentation in Documentation/dev-tools/kunit
+
+	  Run all KUnit tests for Clavis with:
+	  ./tools/testing/kunit/kunit.py run --kunitconfig security/clavis
+
+	  If you are unsure how to answer this question, answer N.
diff --git a/security/clavis/Makefile b/security/clavis/Makefile
index af68a44a0cb4..c0915af4f180 100644
--- a/security/clavis/Makefile
+++ b/security/clavis/Makefile
@@ -3,6 +3,7 @@
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis.o
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis_builtin_acl.o
+obj-$(CONFIG_SECURITY_CLAVIS_KUNIT_TEST) += clavis_test.o
 
 ifeq ($(CONFIG_SECURITY_CLAVIS_ACL_LIST),)
 quiet_cmd_make_builtin_acl = GEN     $@
@@ -22,3 +23,134 @@ $(obj)/clavis_builtin_acl.o: $(obj)/builtin_acl
 ifeq ($(CONFIG_EFI),y)
 obj-$(CONFIG_SECURITY_CLAVIS) += clavis_efi.o
 endif
+
+ifeq ($(CONFIG_SECURITY_CLAVIS_KUNIT_TEST),y)
+ctv := include/generated/clavis
+$(shell mkdir -p $(ctv))
+
+quiet_cmd_make_test_key = GEN     $@
+	cmd_make_test_key = \
+		openssl req -x509 -out $@ -outform der -keyout \
+		$@.priv -new \
+		-nodes -sha512 -days 3650   -subj '/CN=Clavis Kunit' -extensions EXT -config <( \
+		printf "[cert]\nCN=Clavis Kunit\n[req]\ndistinguished_name =  cert\ndefault_bits \
+		= 4096\n[EXT]\nkeyUsage=keyCertSign,digitalSignature\n\
+		extendedKeyUsage=codeSigning\nsubjectKeyIdentifier=hash\n\
+		basicConstraints=critical,CA:TRUE\nauthorityKeyIdentifier=keyid:always,issuer") \
+		> /dev/null 2>&1
+
+# These are in the same order as enum key_being_used_for
+KEY_USAGE = 0 1 2 3 4 5
+CLAVIS_KEYS = 0 1
+
+$(ctv)/ctv_%.x509: FORCE
+	$(call if_changed,make_test_key)
+
+quiet_cmd_make_include_bin_array = GEN	$@
+	cmd_make_include_bin_array = \
+	echo "/* Autogenerated file, do not modify. */" > $@;	\
+	for cfile in $(filter-out FORCE $(ctv)/x509.h $(ctv)/acl.h,$^); do		\
+		filename=$$(basename $$cfile);	\
+		varname=$$(echo "$$filename" | sed 's/\./_/g'); \
+		{ echo -n "const u32 $$varname"_len" = "; \
+		cat $$cfile | wc -c | tr -d '\n'; echo ";"; \
+		echo "const u8 $$varname[] = {"; \
+		od -t x1 -An -v $$cfile | sed 's/\([0-9a-fA-F]\{2\}\)/0x\1,/g'; \
+		echo "};"; } >> $@;	\
+	done
+
+quiet_cmd_make_include_char_array = GEN	 $@
+	cmd_make_include_char_array = \
+	echo "/* Autogenerated file, do not modify. */" > $@; \
+	for cfile in $(filter-out FORCE $(ctv)/x509.h,$^); do \
+		filename=$$(basename $$cfile);	\
+		varname=$$(echo "$$filename" | sed 's/\./_/g'); \
+		{ echo -n "const char $$varname[] = "\"; \
+		  cat $$cfile; echo "\";"; } >> $@; \
+	done
+
+quiet_cmd_gen_acl = GEN     $@
+	cmd_gen_acl = \
+		{ echo -n $*:; \
+		openssl x509 -in $< -inform der -ext subjectKeyIdentifier -nocert | \
+		tail -n +2 | cut -f4 -d '=' | tr -d ':' | tr '[:upper:]' '[:lower:]' | \
+		tr -d '[:space:]'; } > $@
+
+$(ctv)/ctv_%.x509.acl: $(ctv)/ctv_%.x509 FORCE
+	$(call if_changed,gen_acl)
+
+quiet_cmd_ca0_sign_pkcs7 = GEN    $@
+	cmd_ca0_sign_pkcs7 = \
+		openssl smime -sign -signer $(ctv)/ctv_ca0.x509 -inkey \
+		$(ctv)/ctv_ca0.x509.priv -in $< -out $@ -binary -outform DER \
+		-nodetach -noattr > /dev/null 2>&1
+
+$(ctv)/ctv_ca0_%.pkcs7: $(ctv)/ctv_%.x509.acl $(ctv)/ctv_ca0.x509 FORCE
+	$(call if_changed,ca0_sign_pkcs7)
+
+quiet_cmd_ca1_sign_pkcs7 = GEN     $@
+	cmd_ca1_sign_pkcs7 = \
+		openssl smime -sign -signer $(ctv)/ctv_ca1.x509 -inkey \
+		$(ctv)/ctv_ca1.x509.priv -in $< -out $@ -binary -outform DER \
+		-nodetach -noattr > /dev/null 2>&1
+
+$(ctv)/ctv_ca1_%.pkcs7: $(ctv)/ctv_%.x509.acl $(ctv)/ctv_ca1.x509 FORCE
+	$(call if_changed,ca1_sign_pkcs7)
+
+quiet_cmd_sign_data_pkcs7 = GEN    $@
+	cmd_sign_data_pkcs7 = \
+		openssl smime -sign -signer $(ctv)/ctv_$*.x509 -inkey \
+		$(ctv)/ctv_$*.x509.priv -in $< -out $@ -binary -outform DER \
+		-nodetach -noattr > /dev/null 2>&1
+
+quiet_cmd_gen_file = GEN     $@
+	cmd_gen_file = head -c 4096 /dev/urandom > $@
+
+$(ctv)/ctv_data_%_signed: $(ctv)/ctv_%.x509 FORCE
+	$(call cmd,gen_file)
+	$(call cmd,sign_data_pkcs7)
+
+quiet_cmd_copy_sign-file = COPY    $@
+	cmd_copy_sign-file = cat $(src)/../../scripts/sign-file.c >$@
+
+quiet_cmd_sign = KSIGN   $@
+	cmd_sign = $(obj)/sign-file sha256 $<.priv $< $@
+
+$(src)/sign-file.c: FORCE
+	$(call cmd,copy_sign-file)
+
+hostprogs := sign-file
+HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 3> /dev/null) -I$(srctree)/scripts
+HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto)
+
+$(ctv)/ctv_module_%_signed: $(ctv)/ctv_%.x509 $(obj)/sign-file FORCE
+	$(call cmd,gen_file)
+	$(call cmd,sign)
+
+$(ctv)/x509.h: $(foreach n, $(KEY_USAGE), $(ctv)/ctv_0$n.x509)  $(ctv)/ctv_rev.x509 \
+		   $(foreach n, $(CLAVIS_KEYS), $(ctv)/ctv_ca$n.x509) FORCE
+	$(call if_changed,make_include_bin_array)
+
+$(ctv)/acl.h: $(ctv)/x509.h $(foreach n, $(KEY_USAGE), $(ctv)/ctv_0$n.x509.acl) FORCE
+	$(call if_changed,make_include_char_array)
+
+$(ctv)/signed_data.h: $(ctv)/x509.h $(ctv)/acl.h \
+			  $(foreach n, $(KEY_USAGE), $(ctv)/ctv_ca0_0$n.pkcs7) \
+			  $(foreach n, $(KEY_USAGE), $(ctv)/ctv_ca1_0$n.pkcs7) \
+			  $(ctv)/ctv_module_00_signed $(ctv)/ctv_module_ca0_signed \
+			  $(ctv)/ctv_module_rev_signed $(ctv)/ctv_data_05_signed FORCE
+	$(call if_changed,make_include_bin_array)
+
+targets += $(foreach n, $(CLAVIS_KEYS), $(ctv)/ctv_ca$n.x509)
+targets += $(foreach n, $(KEY_USAGE), $(ctv)/ctv_0$n.x509)
+targets += $(foreach n, $(KEY_USAGE), $(ctv)/ctv_0$n.x509.acl)
+targets += $(foreach n, $(KEY_USAGE), $(ctv)/ctv_ca0_0$n.pkcs7)
+targets += $(foreach n, $(KEY_USAGE), $(ctv)/ctv_ca1_0$n.pkcs7)
+targets += $(ctv)/x509.h $(ctv)/acl.h $(ctv)/signed_data.h
+targets += $(ctv)/ctv_module_00_signed $(ctv)/ctv_module_ca0_signed
+targets += $(ctv)/ctv_module_rev_signed $(ctv)/ctv_data_05_signed
+targets += $(ctv)/ctv_rev.x509
+targets += $(src)/sign-file.c $(obj)/sign-file
+
+$(obj)/clavis_test.o: $(ctv)/x509.h $(ctv)/acl.h $(ctv)/signed_data.h
+endif
diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
index 6f68b560311e..2f08c8af1d66 100644
--- a/security/clavis/clavis.h
+++ b/security/clavis/clavis.h
@@ -35,4 +35,28 @@ static inline int __init clavis_efi_param(struct asymmetric_key_id *kid, int len
 
 int __init clavis_keyring_init(void);
 int clavis_sig_verify(const struct key *key, const struct public_key_signature *sig);
+#ifdef CONFIG_SECURITY_CLAVIS_KUNIT_TEST
+extern void key_type_put(struct key_type *ktype);
+extern struct key_type *key_type_lookup(const char *type);
+extern long keyctl_update_key(key_serial_t id, const void __user *_payload, size_t plen);
+extern struct key * (* const clavis_keyring_get_fn_ptr)(void);
+extern int (* const key_acl_preparse_fn_ptr)(struct key_preparsed_payload *prep);
+extern void (* const clavis_add_acl_fn_ptr)(const char *const *skid_list, struct key *keyring);
+
+extern struct key *
+	(*const keyring_alloc_fn_ptr)(const char *desc, struct key_restriction *restriction);
+
+extern struct key_restriction *
+	(* const restriction_alloc_fn_ptr)(key_restrict_link_func_t check_func);
+
+extern struct asymmetric_key_id  *
+	(* const parse_boot_param_fn_ptr)(char *kid, struct asymmetric_key_id *akid,
+					  int akid_max_len);
+
+extern int
+	(* const pkcs7_preparse_content_fn_ptr)(void *ctx, const void *data, size_t len,
+						size_t asn1hdrlen);
+
+extern bool (* const clavis_acl_enforced_fn_ptr)(void);
+#endif
 #endif /* _SECURITY_CLAVIS_H_ */
diff --git a/security/clavis/clavis_test.c b/security/clavis/clavis_test.c
new file mode 100644
index 000000000000..67fe5d6c6037
--- /dev/null
+++ b/security/clavis/clavis_test.c
@@ -0,0 +1,566 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <kunit/test.h>
+#include <kunit/static_stub.h>
+#include <linux/init.h>
+#include <linux/key-type.h>
+#include <keys/asymmetric-type.h>
+#include <linux/vmalloc.h>
+#include <linux/uaccess.h>
+#include <linux/module_signature.h>
+#include <keys/system_keyring.h>
+#include <linux/cred.h>
+#include "clavis.h"
+#include <generated/clavis/x509.h>
+#include <generated/clavis/acl.h>
+#include <generated/clavis/signed_data.h>
+
+static struct key *machine_keyring;
+static struct key *clavis_keyring;
+static bool clavis_enforced;
+
+const char *const clavis_builtin_test_acl_list[] = {
+	"01:02b4e19c7efc4512ae4911d9e7e6c3c9",
+	"05:b6c202e7710544a885e425387cd344f6",
+	"04:ca5b4645541c4e828ef460806f9a61bc",
+	NULL
+};
+
+static int clavis_suite_init(struct kunit_suite *suite)
+{
+	kunit_info(suite, "Initializing Clavis Suite\n");
+
+	machine_keyring = keyring_alloc(".machine_kunit",
+					GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
+					(KEY_POS_ALL & ~KEY_POS_SETATTR) |
+					KEY_USR_VIEW | KEY_USR_READ |
+					KEY_USR_SEARCH,
+					KEY_ALLOC_NOT_IN_QUOTA,
+					NULL, NULL);
+
+	x509_load_certificate_list(ctv_00_x509, ctv_00_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_01_x509, ctv_01_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_02_x509, ctv_02_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_03_x509, ctv_03_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_04_x509, ctv_04_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_05_x509, ctv_05_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_ca0_x509, ctv_ca0_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_ca1_x509, ctv_ca1_x509_len, machine_keyring);
+	x509_load_certificate_list(ctv_rev_x509, ctv_rev_x509_len, machine_keyring);
+
+	/*
+	 * Note, this will leave the machine with one additional revocation in the
+	 * blacklist keyring when done.
+	 */
+	add_key_to_revocation_list(ctv_rev_x509, ctv_rev_x509_len);
+
+	return 0;
+}
+
+static void clavis_suite_exit(struct kunit_suite *suite)
+{
+	key_put(machine_keyring);
+}
+
+static int restrict_link_for_clavis_test(struct key *dest_keyring, const struct key_type *type,
+					 const union key_payload *payload, struct key *restrict_key)
+{
+	struct key_type *clavis;
+	int rval = 0;
+
+	if (type == &key_type_asymmetric && dest_keyring == clavis_keyring && !clavis_enforced) {
+		clavis_enforced = true;
+		return 0;
+	}
+
+	clavis = key_type_lookup("clavis_key_acl");
+	if (type != clavis)
+		rval = -EOPNOTSUPP;
+
+	if (clavis != ERR_PTR(-ENOKEY))
+		key_type_put(clavis);
+
+	return rval;
+}
+
+static int clavis_test_keyring_init(struct kunit *test)
+{
+	struct key_restriction *restriction;
+
+	restriction = restriction_alloc_fn_ptr(restrict_link_for_clavis_test);
+	KUNIT_EXPECT_NOT_ERR_OR_NULL(test, restriction);
+	clavis_keyring = keyring_alloc_fn_ptr(".clavis_test", restriction);
+	KUNIT_EXPECT_NOT_ERR_OR_NULL(test, clavis_keyring);
+	KUNIT_EXPECT_EQ(test, clavis_keyring->perm, KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
+			KEY_POS_WRITE | KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH |
+			KEY_USR_WRITE);
+	clavis_enforced = false;
+	return 0;
+}
+
+static void clavis_test_keyring_exit(struct kunit *test)
+{
+	key_put(clavis_keyring);
+	clavis_keyring = NULL;
+	clavis_enforced = false;
+}
+
+static void builtin_acl_tests(struct kunit *test)
+{
+	key_ref_t key;
+	const char *const *desc;
+
+	clavis_add_acl_fn_ptr(clavis_builtin_test_acl_list, clavis_keyring);
+
+	for (desc = clavis_builtin_test_acl_list; *desc; desc++) {
+		key = keyring_search(make_key_ref(clavis_keyring, true),
+				     key_type_lookup("clavis_key_acl"),
+				     *desc,
+				     true);
+		KUNIT_EXPECT_FALSE(test, (IS_ERR(key)));
+		KUNIT_EXPECT_EQ(test, strcmp(key_ref_to_ptr(key)->description, *desc), 0);
+		KUNIT_EXPECT_EQ(test,
+				keyctl_update_key(key_ref_to_ptr(key)->serial, NULL, 0),
+				-EACCES);
+		KUNIT_EXPECT_EQ(test, key_ref_to_ptr(key)->perm, KEY_POS_SEARCH | KEY_POS_VIEW |
+				KEY_USR_SEARCH | KEY_USR_VIEW);
+		key_ref_put(key);
+	}
+}
+
+static void register_key_type_tests(struct kunit *test)
+{
+	struct key_type *clavis;
+
+	clavis = key_type_lookup("clavis_key_acl");
+	KUNIT_EXPECT_PTR_NE(test, clavis, ERR_PTR(-ENOKEY));
+	if (clavis != ERR_PTR(-ENOKEY))
+		key_type_put(clavis);
+
+	clavis = key_type_lookup("bogus");
+	KUNIT_EXPECT_PTR_EQ(test, clavis, ERR_PTR(-ENOKEY));
+	if (clavis != ERR_PTR(-ENOKEY))
+		key_type_put(clavis);
+}
+
+static void clavis_parse_boot_param_tests(struct kunit *test)
+{
+	char *huge = "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01";
+	struct asymmetric_setup_kid ask;
+	struct asymmetric_key_id *kid;
+
+	KUNIT_EXPECT_PTR_EQ(test, parse_boot_param_fn_ptr(NULL, &ask.id, ARRAY_SIZE(ask.data)),
+			    NULL);
+	KUNIT_EXPECT_PTR_EQ(test, parse_boot_param_fn_ptr(huge, &ask.id, ARRAY_SIZE(ask.data)),
+			    NULL);
+	KUNIT_EXPECT_PTR_EQ(test, parse_boot_param_fn_ptr("0x1000", &ask.id, ARRAY_SIZE(ask.data)),
+			    NULL);
+	KUNIT_EXPECT_PTR_EQ(test, parse_boot_param_fn_ptr("nothex", &ask.id, ARRAY_SIZE(ask.data)),
+			    NULL);
+	kid = parse_boot_param_fn_ptr("01234567", &ask.id, ARRAY_SIZE(ask.data));
+
+	KUNIT_EXPECT_EQ(test, kid->len, 4);
+	KUNIT_EXPECT_EQ(test, kid->data[0], 0x01);
+	KUNIT_EXPECT_EQ(test, kid->data[1], 0x23);
+	KUNIT_EXPECT_EQ(test, kid->data[2], 0x45);
+	KUNIT_EXPECT_EQ(test, kid->data[3], 0x67);
+}
+
+static inline bool vet_description_test(struct key *keyring, const char *desc)
+{
+	key_ref_t key;
+
+	key = key_create(make_key_ref(keyring, true),
+			 "clavis_key_acl",
+			  desc,
+			  NULL,
+			  0,
+			  KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH | KEY_USR_VIEW,
+			  KEY_ALLOC_BUILT_IN);
+
+	if (IS_ERR(key))
+		return false;
+
+	return true;
+}
+
+static void key_acl_vet_description_tests(struct kunit *test)
+{
+	char *huge = "01:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01";
+	char *large = "01:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef";
+	char buf[64];
+	int i;
+
+	KUNIT_EXPECT_FALSE(test, vet_description_test(clavis_keyring, "00:nothex"));
+	KUNIT_EXPECT_FALSE(test, vet_description_test(clavis_keyring, "0:1234"));
+	KUNIT_EXPECT_FALSE(test, vet_description_test(clavis_keyring, "01:123"));
+	KUNIT_EXPECT_FALSE(test, vet_description_test(clavis_keyring, "X0:123"));
+	KUNIT_EXPECT_FALSE(test, vet_description_test(clavis_keyring, huge));
+	KUNIT_EXPECT_TRUE(test, vet_description_test(clavis_keyring, large));
+
+	for (i = 0; i < 255; i++) {
+		snprintf(buf, sizeof(buf), "%2hx:01234567", i);
+		if (i < VERIFYING_CLAVIS_SIGNATURE)
+			KUNIT_EXPECT_TRUE(test, vet_description_test(clavis_keyring, buf));
+		else
+			KUNIT_EXPECT_FALSE(test, vet_description_test(clavis_keyring, buf));
+	}
+}
+
+static void key_usage_tests(struct kunit *test)
+{
+	KUNIT_EXPECT_EQ(test, VERIFYING_CLAVIS_SIGNATURE + 1, NR__KEY_BEING_USED_FOR);
+}
+
+static int key_acl_preparse_kunit(struct key_preparsed_payload *prep)
+{
+	if (prep->orig_description)
+		return 0;
+
+	return verify_pkcs7_signature(NULL, 0, prep->data, prep->datalen, clavis_keyring,
+				      VERIFYING_CLAVIS_SIGNATURE, pkcs7_preparse_content_fn_ptr,
+				      prep);
+}
+
+static void signed_acl_tests(struct kunit *test)
+{
+	int i;
+	const unsigned char *ca0_acl_pkcs7[] = { ctv_ca0_00_pkcs7, ctv_ca0_01_pkcs7,
+						 ctv_ca0_02_pkcs7, ctv_ca0_03_pkcs7,
+						 ctv_ca0_04_pkcs7, ctv_ca0_05_pkcs7
+					       };
+
+	const u32 ca0_acl_pkcs7_buf_size[] = { ctv_ca0_00_pkcs7_len, ctv_ca0_01_pkcs7_len,
+					       ctv_ca0_02_pkcs7_len, ctv_ca0_03_pkcs7_len,
+					       ctv_ca0_04_pkcs7_len, ctv_ca0_05_pkcs7_len
+					     };
+
+	const unsigned char *ca1_acl_pkcs7[] = { ctv_ca1_00_pkcs7, ctv_ca1_01_pkcs7,
+						 ctv_ca1_02_pkcs7, ctv_ca1_03_pkcs7,
+						 ctv_ca1_04_pkcs7, ctv_ca1_05_pkcs7
+					       };
+
+	const u32 ca1_acl_pkcs7_buf_size[] = { ctv_ca1_00_pkcs7_len, ctv_ca1_01_pkcs7_len,
+					       ctv_ca1_02_pkcs7_len, ctv_ca1_03_pkcs7_len,
+					       ctv_ca1_04_pkcs7_len, ctv_ca1_05_pkcs7_len
+					     };
+
+	char const *acl_list[] = { ctv_00_x509_acl, ctv_01_x509_acl, ctv_02_x509_acl,
+				   ctv_03_x509_acl, ctv_04_x509_acl, ctv_05_x509_acl };
+
+	key_ref_t key;
+
+	KUNIT_EXPECT_EQ(test,
+			x509_load_certificate_list(ctv_ca0_x509, ctv_ca0_x509_len, clavis_keyring),
+			0);
+
+	clavis_enforced = true;
+
+	for (i = 0; i < 6; i++) {
+		key = key_create(make_key_ref(clavis_keyring, true),
+				 "clavis_key_acl",
+				 NULL,
+				 ca0_acl_pkcs7[i],
+				 ca0_acl_pkcs7_buf_size[i],
+				 KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH | KEY_USR_VIEW,
+				 KEY_ALLOC_BUILT_IN);
+
+		KUNIT_EXPECT_TRUE(test, IS_ERR(key));
+
+		key = keyring_search(make_key_ref(clavis_keyring, true),
+				     key_type_lookup("clavis_key_acl"),
+				     acl_list[i],
+				     true);
+
+		KUNIT_EXPECT_TRUE(test, IS_ERR(key));
+	}
+
+	kunit_activate_static_stub(test, key_acl_preparse_fn_ptr, key_acl_preparse_kunit);
+
+	for (i = 0; i < 6; i++) {
+		key = key_create(make_key_ref(clavis_keyring, true),
+				 "clavis_key_acl",
+				 NULL,
+				 ca0_acl_pkcs7[i],
+				 ca0_acl_pkcs7_buf_size[i],
+				 KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH | KEY_USR_VIEW,
+				 KEY_ALLOC_BUILT_IN);
+
+		KUNIT_EXPECT_NOT_ERR_OR_NULL(test, key);
+
+		key = keyring_search(make_key_ref(clavis_keyring, true),
+				     key_type_lookup("clavis_key_acl"),
+				     acl_list[i],
+				     true);
+
+		KUNIT_EXPECT_NOT_ERR_OR_NULL(test, key);
+	}
+
+	for (i = 0; i < 6; i++) {
+		key = key_create(make_key_ref(clavis_keyring, true),
+				 "clavis_key_acl",
+				 NULL,
+				 ca1_acl_pkcs7[i],
+				 ca1_acl_pkcs7_buf_size[i],
+				 KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH | KEY_USR_VIEW,
+				 KEY_ALLOC_BUILT_IN);
+
+		KUNIT_EXPECT_TRUE(test, IS_ERR(key));
+	}
+
+	kunit_deactivate_static_stub(test, key_acl_preparse_fn_ptr);
+}
+
+static struct key *clavis_key_get(void)
+{
+	return clavis_keyring;
+}
+
+static bool clavis_acl_enforced(void)
+{
+	return clavis_enforced;
+}
+
+static void module_invalid_signed_tests(struct kunit *test)
+{
+	const void *mod = ctv_module_ca0_signed;
+	struct module_signature ms;
+	key_ref_t key;
+	size_t sig_len, mod_len;
+
+	kunit_activate_static_stub(test, clavis_keyring_get_fn_ptr, clavis_key_get);
+	kunit_activate_static_stub(test, clavis_acl_enforced_fn_ptr, clavis_acl_enforced);
+
+	/* Remove the module signature appended information at the end. */
+	mod_len = ctv_module_ca0_signed_len - 28;
+	KUNIT_EXPECT_GT(test, mod_len, sizeof(ms));
+	memcpy(&ms, mod + (mod_len - sizeof(ms)), sizeof(ms));
+	sig_len = be32_to_cpu(ms.sig_len);
+	mod_len -= sig_len + sizeof(ms);
+
+	/*
+	 * Enforcement has not been set yet, therefore the verification passes
+	 * without an ACL. The module signing key is in the machine_kunit
+	 * keyring.
+	 */
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), 0);
+
+	/* Load the clavis CA0 in the clavis keyring. */
+	KUNIT_EXPECT_EQ(test,
+			x509_load_certificate_list(ctv_ca0_x509, ctv_ca0_x509_len, clavis_keyring),
+			0);
+
+	clavis_enforced = true;
+
+	/* Enforcement has been enabled without an ACL set. */
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), -EKEYREJECTED);
+
+	/* Add the module ACL. */
+	key = key_create(make_key_ref(clavis_keyring, true),
+			 "clavis_key_acl",
+			 NULL,
+			 ctv_ca0_00_pkcs7,
+			 ctv_ca0_00_pkcs7_len,
+			 KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH |
+			 KEY_USR_VIEW, KEY_ALLOC_BUILT_IN);
+
+	KUNIT_EXPECT_FALSE(test, IS_ERR(key));
+
+	/* This module was not signed by the module ACL in the clavis keyring. */
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), -EKEYREJECTED);
+
+	kunit_deactivate_static_stub(test, clavis_keyring_get_fn_ptr);
+	kunit_deactivate_static_stub(test, clavis_acl_enforced_fn_ptr);
+}
+
+static void module_signed_tests(struct kunit *test)
+{
+	const void *mod = ctv_module_00_signed;
+	struct module_signature ms;
+	key_ref_t key;
+	size_t sig_len, mod_len;
+
+	kunit_activate_static_stub(test, clavis_keyring_get_fn_ptr, clavis_key_get);
+	kunit_activate_static_stub(test, clavis_acl_enforced_fn_ptr, clavis_acl_enforced);
+
+	/* Remove the module signature appended information at the end. */
+	mod_len = ctv_module_00_signed_len - 28;
+	KUNIT_EXPECT_GT(test, mod_len, sizeof(ms));
+	memcpy(&ms, mod + (mod_len - sizeof(ms)), sizeof(ms));
+	sig_len = be32_to_cpu(ms.sig_len);
+	mod_len -= sig_len + sizeof(ms);
+
+	/*
+	 * Enforcement has not been set yet, therefore the verification passes
+	 * without an ACL.
+	 */
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), 0);
+
+	/* Load the clavis CA0 in the clavis keyring. */
+	KUNIT_EXPECT_EQ(test,
+			x509_load_certificate_list(ctv_ca0_x509, ctv_ca0_x509_len, clavis_keyring),
+			0);
+
+	clavis_enforced = true;
+
+	/* Enforcement has been enabled without an ACL set. */
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), -EKEYREJECTED);
+
+	/* Add the module ACL. */
+	key = key_create(make_key_ref(clavis_keyring, true),
+			 "clavis_key_acl",
+			 NULL,
+			 ctv_ca0_00_pkcs7,
+			 ctv_ca0_00_pkcs7_len,
+			 KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH |
+			 KEY_USR_VIEW, KEY_ALLOC_BUILT_IN);
+
+	KUNIT_EXPECT_FALSE(test, IS_ERR(key));
+
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), 0);
+
+	kunit_deactivate_static_stub(test, clavis_keyring_get_fn_ptr);
+	kunit_deactivate_static_stub(test, clavis_acl_enforced_fn_ptr);
+}
+
+static void module_revocation_tests(struct kunit *test)
+{
+	/*
+	 * When this test starts, the cert used to sign the module is both in
+	 * the machine_kunit keyring and the blacklist keyring.  Also the
+	 * clavis_kunit is not in enforcement mode. This will test the
+	 * PKS_REVOCATION_PASS.
+	 */
+
+	const void *mod = ctv_module_rev_signed;
+	struct module_signature ms;
+	size_t sig_len, mod_len;
+
+	kunit_activate_static_stub(test, clavis_keyring_get_fn_ptr, clavis_key_get);
+	kunit_activate_static_stub(test, clavis_acl_enforced_fn_ptr, clavis_acl_enforced);
+
+	/* Remove the module signature appended information at the end. */
+	mod_len = ctv_module_rev_signed_len - 28;
+	KUNIT_EXPECT_GT(test, mod_len, sizeof(ms));
+	memcpy(&ms, mod + (mod_len - sizeof(ms)), sizeof(ms));
+	sig_len = be32_to_cpu(ms.sig_len);
+	mod_len -= sig_len + sizeof(ms);
+
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), -EKEYREJECTED);
+
+	clavis_enforced = true;
+
+	KUNIT_EXPECT_EQ(test, verify_pkcs7_signature(mod, mod_len,
+						     mod + mod_len, sig_len,
+						     machine_keyring,
+						     VERIFYING_MODULE_SIGNATURE,
+						     NULL, NULL), -EKEYREJECTED);
+
+	kunit_deactivate_static_stub(test, clavis_keyring_get_fn_ptr);
+	kunit_deactivate_static_stub(test, clavis_acl_enforced_fn_ptr);
+}
+
+static void unspecified_signed_tests(struct kunit *test)
+{
+	key_ref_t key;
+
+	kunit_activate_static_stub(test, clavis_keyring_get_fn_ptr, clavis_key_get);
+	kunit_activate_static_stub(test, clavis_acl_enforced_fn_ptr, clavis_acl_enforced);
+
+	KUNIT_EXPECT_EQ(test,
+			verify_pkcs7_signature(NULL, 0, ctv_data_05_signed, ctv_data_05_signed_len,
+					       machine_keyring,
+					       VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL),
+			0);
+
+	/* Load the clavis CA0 in the clavis keyring. */
+	KUNIT_EXPECT_EQ(test,
+			x509_load_certificate_list(ctv_ca0_x509, ctv_ca0_x509_len, clavis_keyring),
+			0);
+
+	clavis_enforced = true;
+
+	KUNIT_EXPECT_EQ(test,
+			verify_pkcs7_signature(NULL, 0, ctv_data_05_signed, ctv_data_05_signed_len,
+					       machine_keyring,
+					       VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL),
+			-EKEYREJECTED);
+
+	/* Add the unspecified ACL. */
+	key = key_create(make_key_ref(clavis_keyring, true),
+			 "clavis_key_acl",
+			 NULL,
+			 ctv_ca0_05_pkcs7,
+			 ctv_ca0_05_pkcs7_len,
+			 KEY_POS_SEARCH | KEY_POS_VIEW | KEY_USR_SEARCH |
+			 KEY_USR_VIEW, KEY_ALLOC_BUILT_IN);
+
+	KUNIT_EXPECT_FALSE(test, IS_ERR(key));
+
+	KUNIT_EXPECT_EQ(test,
+			verify_pkcs7_signature(NULL, 0, ctv_data_05_signed, ctv_data_05_signed_len,
+					       machine_keyring,
+					       VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL),
+			0);
+
+	KUNIT_EXPECT_EQ(test,
+			verify_pkcs7_signature(NULL, 0, ctv_data_05_signed, ctv_data_05_signed_len,
+					       machine_keyring,
+					       VERIFYING_MODULE_SIGNATURE, NULL, NULL),
+			-EKEYREJECTED);
+
+	kunit_deactivate_static_stub(test, clavis_keyring_get_fn_ptr);
+	kunit_deactivate_static_stub(test, clavis_acl_enforced_fn_ptr);
+}
+
+static struct kunit_case clavis_test_cases[] = {
+	KUNIT_CASE(builtin_acl_tests),
+	KUNIT_CASE(register_key_type_tests),
+	KUNIT_CASE(clavis_parse_boot_param_tests),
+	KUNIT_CASE(key_acl_vet_description_tests),
+	KUNIT_CASE(key_usage_tests),
+	KUNIT_CASE(signed_acl_tests),
+	KUNIT_CASE(module_signed_tests),
+	KUNIT_CASE(module_invalid_signed_tests),
+	KUNIT_CASE(module_revocation_tests),
+	KUNIT_CASE(unspecified_signed_tests),
+	{}
+};
+
+static struct kunit_suite clavis_test_suite = {
+	.name = "clavis",
+	.suite_init = clavis_suite_init,
+	.suite_exit = clavis_suite_exit,
+	.init = clavis_test_keyring_init,
+	.exit = clavis_test_keyring_exit,
+	.test_cases = clavis_test_cases,
+};
+
+kunit_test_suites(&clavis_test_suite);
-- 
2.45.0

Re: [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check

[Jarkko Sakkinen]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this
> pattern does not need to be repeated with new code.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  certs/system_keyring.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 9de610bf1f4b..e344cee10d28 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys;
>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
>  static struct key *machine_trusted_keys;
>  #endif
> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
>  static struct key *platform_trusted_keys;
> -#endif
>  
>  extern __initconst const u8 system_certificate_list[];
>  extern __initconst const unsigned long system_certificate_list_size;
> @@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data,
> size_t len,
>  		trusted_keys = builtin_trusted_keys;
>  #endif
>  	} else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
>  		trusted_keys = platform_trusted_keys;
> -#else
> -		trusted_keys = NULL;
> -#endif
>  		if (!trusted_keys) {
>  			ret = -ENOKEY;
>  			pr_devel("PKCS#7 platform keyring is not
> available\n");

Just to check with the argument that any commit should bring the Git
tree to another "good state". Why this was flagged? What would be the
collateral damage if only this commit was picked and put to a pull
request? No intentions to do that, this more like forming a better
understanding what is at stake here.

I.e. I get that you need this for subsequent commits but I think the
commit message should also have like explanation why this is a legit
change otherwise.

I mean, less flagging better if it does not cause harm is already
great without higher level goals.

BR, Jarkko

Re: [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key

[Jarkko Sakkinen]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Introduce system_key_link(), a new function to allow a keyring to
> link
> to a key contained within one of the system keyrings (builtin,
> secondary,
> or platform). Depending on how the kernel is built, if the machine
> keyring is available, it will be checked as well, since it is linked
> to
> the secondary keyring. If the asymmetric key id matches a key within
> one
> of these system keyrings, the matching key is linked into the passed
> in
> keyring.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  certs/system_keyring.c        | 30 ++++++++++++++++++++++++++++++
>  include/keys/system_keyring.h |  7 ++++++-
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index e344cee10d28..4abee7514442 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -20,6 +20,9 @@
>  static struct key *builtin_trusted_keys;
>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
>  static struct key *secondary_trusted_keys;

/*
 * Explain system_trusted_keys (nothing too detailed, only the gist)
 */

> +#define system_trusted_keys secondary_trusted_keys
> +#else
> +#define system_trusted_keys builtin_trusted_keys
>  #endif
>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
>  static struct key *machine_trusted_keys;

We have enough these to make this quite convoluted so let's put some
helpful reminders. I would forget this in no time ;-) So if it comes
down to that, please put something because I have a goldfish memory.

BR, Jarkko

Re: [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check

[Eric Snowberg]

> On Oct 17, 2024, at 10:13 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this
>> pattern does not need to be repeated with new code.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>>  certs/system_keyring.c | 6 ------
>>  1 file changed, 6 deletions(-)
>> 
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index 9de610bf1f4b..e344cee10d28 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys;
>>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
>>  static struct key *machine_trusted_keys;
>>  #endif
>> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
>>  static struct key *platform_trusted_keys;
>> -#endif
>>  
>>  extern __initconst const u8 system_certificate_list[];
>>  extern __initconst const unsigned long system_certificate_list_size;
>> @@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data,
>> size_t len,
>>   trusted_keys = builtin_trusted_keys;
>>  #endif
>>   } else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
>> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
>>   trusted_keys = platform_trusted_keys;
>> -#else
>> - trusted_keys = NULL;
>> -#endif
>>   if (!trusted_keys) {
>>   ret = -ENOKEY;
>>   pr_devel("PKCS#7 platform keyring is not
>> available\n");
> 
> Just to check with the argument that any commit should bring the Git
> tree to another "good state". Why this was flagged? What would be the
> collateral damage if only this commit was picked and put to a pull
> request? No intentions to do that, this more like forming a better
> understanding what is at stake here.
> 
> I.e. I get that you need this for subsequent commits but I think the
> commit message should also have like explanation why this is a legit
> change otherwise.

Thanks for taking a look at this, I will add a better explanation in the
next round. 

Re: [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Jarkko Sakkinen]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> +static struct asymmetric_key_id *clavis_parse_boot_param(char *kid,
> struct asymmetric_key_id *akid,
> +							 int
> akid_max_len)
> +{
> +	int error, hex_len;
> +
> +	if (!kid)
> +		return 0;
> +
> +	hex_len = strlen(kid) / 2;

Hmmm... I'd consider sanity checking this:

	size_t len;

	/* ... */

	len = strlen(kid);
	if (len % 2) {
		pr_err("Clavis key id has invalid length %lu\n", len);
		return 0;
	}

	hex_len = len / 2;
	
BR, Jarkko

Re: [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key

[Eric Snowberg]

> On Oct 17, 2024, at 10:16 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Introduce system_key_link(), a new function to allow a keyring to
>> link
>> to a key contained within one of the system keyrings (builtin,
>> secondary,
>> or platform). Depending on how the kernel is built, if the machine
>> keyring is available, it will be checked as well, since it is linked
>> to
>> the secondary keyring. If the asymmetric key id matches a key within
>> one
>> of these system keyrings, the matching key is linked into the passed
>> in
>> keyring.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>>  certs/system_keyring.c        | 30 ++++++++++++++++++++++++++++++
>>  include/keys/system_keyring.h |  7 ++++++-
>>  2 files changed, 36 insertions(+), 1 deletion(-)
>> 
>> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
>> index e344cee10d28..4abee7514442 100644
>> --- a/certs/system_keyring.c
>> +++ b/certs/system_keyring.c
>> @@ -20,6 +20,9 @@
>>  static struct key *builtin_trusted_keys;
>>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
>>  static struct key *secondary_trusted_keys;
> 
> /*
> * Explain system_trusted_keys (nothing too detailed, only the gist)
> */
> 
>> +#define system_trusted_keys secondary_trusted_keys
>> +#else
>> +#define system_trusted_keys builtin_trusted_keys
>>  #endif
>>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
>>  static struct key *machine_trusted_keys;
> 
> We have enough these to make this quite convoluted so let's put some
> helpful reminders. I would forget this in no time ;-) So if it comes
> down to that, please put something because I have a goldfish memory.

I'll add a comment explaining this in the next round, thanks.

Re: [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)

[Jarkko Sakkinen]

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

BR, Jarkko

Re: [RFC PATCH v3 06/13] clavis: Populate clavis keyring acl with kernel module signature

[Jarkko Sakkinen]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> If the kernel is built with CONFIG_MODULE_SIG_KEY, get the subject
> key identifier and add an ACL for it within the .clavis keyring.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Super sound splits! Nice to review, have to give credit on this
:-)

> ---
>  certs/.gitignore                 |  1 +
>  certs/Makefile                   | 20 ++++++++++++++++++++
>  certs/clavis_module_acl.c        |  7 +++++++
>  security/clavis/clavis.h         |  9 +++++++++
>  security/clavis/clavis_keyring.c | 27 +++++++++++++++++++++++++++
>  5 files changed, 64 insertions(+)
>  create mode 100644 certs/clavis_module_acl.c
> 
> diff --git a/certs/.gitignore b/certs/.gitignore
> index cec5465f31c1..dc99ae5a2585 100644
> --- a/certs/.gitignore
> +++ b/certs/.gitignore
> @@ -3,3 +3,4 @@
>  /extract-cert
>  /x509_certificate_list
>  /x509_revocation_list
> +/module_acl
> diff --git a/certs/Makefile b/certs/Makefile
> index f6fa4d8d75e0..f2555e5296f5 100644
> --- a/certs/Makefile
> +++ b/certs/Makefile
> @@ -6,6 +6,7 @@
>  obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o
> system_certificates.o
>  obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o
> blacklist_hashes.o
>  obj-$(CONFIG_SYSTEM_REVOCATION_LIST) += revocation_certificates.o
> +obj-$(CONFIG_SECURITY_CLAVIS) += clavis_module_acl.o
>  
>  $(obj)/blacklist_hashes.o: $(obj)/blacklist_hash_list
>  CFLAGS_blacklist_hashes.o := -I $(obj)
> @@ -75,6 +76,25 @@ $(obj)/signing_key.x509: $(filter-out
> $(PKCS11_URI),$(CONFIG_MODULE_SIG_KEY)) $(
>  
>  targets += signing_key.x509
>  
> +ifeq ($(CONFIG_MODULE_SIG_KEY),)
> +quiet_cmd_make_module_acl = GEN   $@
> +      cmd_make_module_acl = \
> +	echo > $@
> +else
> +quiet_cmd_make_module_acl = GEN   $@
> +      cmd_make_module_acl = \
> +	openssl x509 -in $< -inform der -ext subjectKeyIdentifier  -
> nocert | \
> +	tail -n +2 | cut -f2 -d '='| tr -d ':' | tr '[:upper:]'
> '[:lower:]' | \
> +	sed 's/^[ \t]*//; s/.*/"00:&",/' > $@
> +endif
> +
> +$(obj)/module_acl: $(obj)/signing_key.x509 FORCE
> +		$(call if_changed,make_module_acl)
> +
> +$(obj)/clavis_module_acl.o: $(obj)/module_acl
> +
> +targets += module_acl
> +
>  $(obj)/revocation_certificates.o: $(obj)/x509_revocation_list
>  
>  $(obj)/x509_revocation_list: $(CONFIG_SYSTEM_REVOCATION_KEYS)
> $(obj)/extract-cert FORCE
> diff --git a/certs/clavis_module_acl.c b/certs/clavis_module_acl.c
> new file mode 100644
> index 000000000000..fc2f694c48f9
> --- /dev/null
> +++ b/certs/clavis_module_acl.c
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/kernel.h>
> +
> +const char __initconst *const clavis_module_acl[] = {
> +#include "module_acl"
> +	NULL
> +};
> diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
> index 7b55a6050440..92f77a1939ad 100644
> --- a/security/clavis/clavis.h
> +++ b/security/clavis/clavis.h
> @@ -11,4 +11,13 @@ struct asymmetric_setup_kid {
>  	struct asymmetric_key_id id;
>  	unsigned char data[CLAVIS_BIN_KID_MAX];
>  };
> +
> +#ifndef CONFIG_SYSTEM_TRUSTED_KEYRING
> +const char __initconst *const clavis_module_acl[] = {
> +	 NULL
> +};
> +#else
> +extern const char __initconst *const clavis_module_acl[];
> +#endif
> +
>  #endif /* _SECURITY_CLAVIS_H_ */
> diff --git a/security/clavis/clavis_keyring.c
> b/security/clavis/clavis_keyring.c
> index 00163e7f0fe9..2a18d0e77189 100644
> --- a/security/clavis/clavis_keyring.c
> +++ b/security/clavis/clavis_keyring.c
> @@ -259,6 +259,31 @@ static struct key_restriction
> *clavis_restriction_alloc(key_restrict_link_func_t
>  	return restriction;
>  }
>  
> +static void clavis_add_acl(const char *const *skid_list, struct key
> *keyring)
> +{
> +	const char *const *acl;
> +	key_ref_t key;
> +
> +	for (acl = skid_list; *acl; acl++) {
> +		key = key_create(make_key_ref(keyring, true),
> +				 "clavis_key_acl",
> +				  *acl,
> +				  NULL,
> +				  0,
> +				  KEY_POS_SEARCH | KEY_POS_VIEW |
> KEY_USR_SEARCH | KEY_USR_VIEW,
> +				  KEY_ALLOC_NOT_IN_QUOTA |
> KEY_ALLOC_BUILT_IN |
> +				  KEY_ALLOC_BYPASS_RESTRICTION);
> +		if (IS_ERR(key)) {
> +			if (PTR_ERR(key) == -EEXIST)
> +				pr_info("Duplicate clavis_key_acl
> %s\n", *acl);
> +			else
> +				pr_info("Problem with clavis_key_acl
> %s: %pe\n", *acl, key);
> +		} else {
> +			pr_info("Added clavis_key_acl %s\n", *acl);
> +		}
> +	}
> +}
> +
>  static int __init clavis_keyring_init(void)
>  {
>  	struct key_restriction *restriction;
> @@ -274,6 +299,8 @@ static int __init clavis_keyring_init(void)
>  	if (IS_ERR(clavis_keyring))
>  		panic("Can't allocate clavis keyring\n");
>  
> +	clavis_add_acl(clavis_module_acl, clavis_keyring);
> +
>  	return 0;
>  }
>  

Not yet tagging, but neither anything to complain. LGTM

BR, Jarkko

Re: [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Eric Snowberg]

> On Oct 17, 2024, at 10:50 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> +static struct asymmetric_key_id *clavis_parse_boot_param(char *kid,
>> struct asymmetric_key_id *akid,
>> + int
>> akid_max_len)
>> +{
>> + int error, hex_len;
>> +
>> + if (!kid)
>> + return 0;
>> +
>> + hex_len = strlen(kid) / 2;
> 
> Hmmm... I'd consider sanity checking this:
> 
> size_t len;
> 
> /* ... */
> 
> len = strlen(kid);
> if (len % 2) {
> pr_err("Clavis key id has invalid length %lu\n", len);
> return 0;
> }
> 
> hex_len = len / 2;
> 

Good catch, I will include this in the next round.  I have also added a kunit test 
for this as well.  Thanks.

Re: [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Jarkko Sakkinen]

On Thu, 2024-10-17 at 20:34 +0000, Eric Snowberg wrote:
> 
> 
> > On Oct 17, 2024, at 10:50 AM, Jarkko Sakkinen <jarkko@kernel.org>
> > wrote:
> > 
> > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> > > +static struct asymmetric_key_id *clavis_parse_boot_param(char
> > > *kid,
> > > struct asymmetric_key_id *akid,
> > > + int
> > > akid_max_len)
> > > +{
> > > + int error, hex_len;
> > > +
> > > + if (!kid)
> > > + return 0;
> > > +
> > > + hex_len = strlen(kid) / 2;
> > 
> > Hmmm... I'd consider sanity checking this:
> > 
> > size_t len;
> > 
> > /* ... */
> > 
> > len = strlen(kid);
> > if (len % 2) {
> > pr_err("Clavis key id has invalid length %lu\n", len);
> > return 0;
> > }
> > 
> > hex_len = len / 2;
> > 
> 
> Good catch, I will include this in the next round.  I have also added
> a kunit test 
> for this as well.  Thanks.

I guess hex2bin() would eventually catch this issue, i.e. not an actual
bug, but I still think that you are better off doing also check here and
get an appropriate message to klog if that ever happens :-)

BR, Jarkko

Re: [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)

[Eric Snowberg]

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

Re: [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)

[Jarkko Sakkinen]

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

Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl

[Ben Boeckel]

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

Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl

[Eric Snowberg]

> On Oct 17, 2024, at 11:21 PM, Ben Boeckel <me@benboeckel.net> wrote:
> 
> 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.

Correct

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

I didn't want to burden the end-user with getting everything in
lowercase, since OpenSSL typically returns the result in uppercase. 
I will add some comments as you suggested incase the kernel 
wants to make such a key internally.

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

This is documented, but it doesn't come in until the 8th patch in the series. 
Hopefully that is not an issue.

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

I'll update the comment.

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

This was done incase the end-user has a trailing carriage return at the
end of their ACL. I have updated the comment as follows:

+       /*
+        * Copy the user supplied contents, if uppercase is used, convert it to
+        * lowercase.  Also if the end of the ACL contains any whitespace, strip
+        * it out.
+        */

> 
>> +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?

All the system kernel keyrings work this way. But now that you bring this up, neither of
these functions are really necessary, so I will remove them in the next round.

>> +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?

I will change this to strlen

>> + /*
>> + * 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…).

and remove the unnecessary check.  Thanks for your review.

Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl

[Ben Boeckel]

On Fri, Oct 18, 2024 at 15:42:15 +0000, Eric Snowberg wrote:
> > On Oct 17, 2024, at 11:21 PM, Ben Boeckel <me@benboeckel.net> wrote:
> > Can this be committed to `Documentation/` and not just the Git history
> > please?
> 
> This is documented, but it doesn't come in until the 8th patch in the series. 
> Hopefully that is not an issue.

Ah, I'll look there, thanks.

> >> + 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.
> 
> This was done incase the end-user has a trailing carriage return at the
> end of their ACL. I have updated the comment as follows:
> 
> +       /*
> +        * Copy the user supplied contents, if uppercase is used, convert it to
> +        * lowercase.  Also if the end of the ACL contains any whitespace, strip
> +        * it out.
> +        */

Well, this doesn't check the end for whitespace; any internal whitespace
will terminate the key:

    DEAD BEEF
        ^ becomes NUL

and results in the same thing as `DEAD` being passed.

> > 
> >> +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?
> 
> All the system kernel keyrings work this way. But now that you bring this up, neither of
> these functions are really necessary, so I will remove them in the next round.
> 
> >> +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?
> 
> I will change this to strlen

Actually, this could probably be `strnlen` using `CLAVIS_ASCII_KID_MAX +
1` just to avoid running off into la-la land when we're going to error
anyways. Or even `8` because we only actually care about "is at least 7
bytes". Worth a comment either way.

Looking forward to the next cycle.

Thanks,

--Ben

Re: [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl

[Eric Snowberg]

> On Oct 18, 2024, at 10:55 AM, Ben Boeckel <me@benboeckel.net> wrote:
> 
> On Fri, Oct 18, 2024 at 15:42:15 +0000, Eric Snowberg wrote:
>> 
>> This was done incase the end-user has a trailing carriage return at the
>> end of their ACL. I have updated the comment as follows:
>> 
>> +       /*
>> +        * Copy the user supplied contents, if uppercase is used, convert it to
>> +        * lowercase.  Also if the end of the ACL contains any whitespace, strip
>> +        * it out.
>> +        */
> 
> Well, this doesn't check the end for whitespace; any internal whitespace
> will terminate the key:
> 
>    DEAD BEEF
>        ^ becomes NUL
> 
> and results in the same thing as `DEAD` being passed.

Originally I was thinking I could extract and fix up the data in pkcs7_preparse_content,
later when key_acl_vet_description gets called do the validation. But I see 
your point that it is possible there could be a valid ACL, followed by a space and
some other data, which should trigger an invalid response.  I'll take care of this in
the next round too.  I'll also add a Kunit test for this one. Thanks.

Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[sergeh]

On Thu, Oct 17, 2024 at 09:55:11AM -0600, Eric Snowberg wrote:
> Introduce a new LSM called clavis.  The motivation behind this LSM is to
> provide access control for system keys.  The access control list is
> contained within a keyring call .clavis.  During boot if the clavis= boot
> arg is supplied with a key id contained within any of the current system
> keyrings (builtin, secondary, machine, or platform) it shall be used as
> the root of trust for validating anything that is added to the ACL list.
> 
> The first restriction introduced with this LSM is the ability to enforce
> key usage.  The kernel already has a notion of tracking key usage.  This
> LSM adds the ability to enforce this usage based on the system owners
> configuration.
> 
> Each system key may have one or more uses defined within the ACL list.
> Until an entry is added to the .clavis keyring, no other system key may
> be used for any other purpose.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++++++++++++++
>  MAINTAINERS                                   |   7 +
>  crypto/asymmetric_keys/signature.c            |   4 +
>  include/linux/lsm_count.h                     |   8 +-
>  include/linux/lsm_hook_defs.h                 |   2 +
>  include/linux/security.h                      |   7 +
>  include/uapi/linux/lsm.h                      |   1 +
>  security/Kconfig                              |  10 +-
>  security/clavis/Makefile                      |   1 +
>  security/clavis/clavis.c                      |  26 +++
>  security/clavis/clavis.h                      |   4 +
>  security/clavis/clavis_keyring.c              |  78 ++++++-
>  security/security.c                           |  13 ++
>  .../selftests/lsm/lsm_list_modules_test.c     |   3 +
>  14 files changed, 346 insertions(+), 9 deletions(-)
>  create mode 100644 Documentation/admin-guide/LSM/clavis.rst
>  create mode 100644 security/clavis/clavis.c
> 
> diff --git a/Documentation/admin-guide/LSM/clavis.rst b/Documentation/admin-guide/LSM/clavis.rst
> new file mode 100644
> index 000000000000..0e924f638a86
> --- /dev/null
> +++ b/Documentation/admin-guide/LSM/clavis.rst
> @@ -0,0 +1,191 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +======
> +Clavis
> +======
> +
> +Clavis is a Linux Security Module that provides mandatory access control to
> +system kernel keys (i.e. builtin, secondary, machine and platform). These
> +restrictions will prohibit keys from being used for validation. Upon boot, the
> +Clavis LSM is provided a key id as a boot parameter.  This single key is then
> +used as the root of trust for any access control modifications made going
> +forward. Access control updates must be signed and validated by this key.
> +
> +Clavis has its own keyring.  All ACL updates are applied through this keyring.
> +The update must be signed by the single root of trust key.
> +
> +When enabled, all system keys are prohibited from being used until an ACL is
> +added for them.
> +
> +On UEFI platforms, the root of trust key shall survive a kexec. Trying to
> +defeat or change it from the command line is not allowed.  The original boot
> +parameter is stored in UEFI and will always be referenced following a kexec.

Does this mean someone can reboot the host, boot another OS, store a key
id in UEFI, and force the root of trust key to be one other than what
the user lists in clavis= boot argument?

Never mind!  Saw the answer in patches 10 and 11, thanks.

> +The Clavis LSM contains a system keyring call .clavis.  It contains a single

s/call/called/

> +asymmetric key that is used to validate anything added to it.  This key can
> +be added during boot and must be a preexisting system kernel key.  If the
> +``clavis=`` boot parameter is not used, any asymmetric key the user owns

Who is "the user", and precisely what does "owns' mean here?  Is it just
restating that it must be a key already in one of the builtin or secondary
or platform keyrings?

And this is done by simply loading it into the clavis keyring, right?

-serge

Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[Eric Snowberg]

> On Oct 22, 2024, at 8:25 PM, sergeh@kernel.org wrote:
> 
> On Thu, Oct 17, 2024 at 09:55:11AM -0600, Eric Snowberg wrote:
>> 
>> +The Clavis LSM contains a system keyring call .clavis.  It contains a single
> 
> s/call/called/

I will change that, thanks.

>> +asymmetric key that is used to validate anything added to it.  This key can
>> +be added during boot and must be a preexisting system kernel key.  If the
>> +``clavis=`` boot parameter is not used, any asymmetric key the user owns
> 
> Who is "the user", and precisely what does "owns' mean here?  Is it just
> restating that it must be a key already in one of the builtin or secondary
> or platform keyrings?

In the case where Clavis was not provided a key id during boot, root can 
add a single public key to the .clavis keyring anytime afterwards.  This 
key does not need to be in any of the system keyrings.  Once the key is 
added, the Clavis LSM is enabled. The root user must also own the private 
key, since this is required to do the ACL signing. I will try to clarify this better 
in the documentation. 

I wouldn't expect this to be the typical way Clavis would be used. I would 
also be interested in any feedback if enabling the Clavis LSM this way 
following boot should be removed.  If this were removed, Clavis could 
only be enabled when using the boot parameter.

> And this is done by simply loading it into the clavis keyring, right?

Correct.

Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[sergeh]

On Wed, Oct 23, 2024 at 07:25:21PM +0000, Eric Snowberg wrote:
> > On Oct 22, 2024, at 8:25 PM, sergeh@kernel.org wrote:
> > 
> > On Thu, Oct 17, 2024 at 09:55:11AM -0600, Eric Snowberg wrote:
> >> 
> >> +The Clavis LSM contains a system keyring call .clavis.  It contains a single
> > 
> > s/call/called/
> 
> I will change that, thanks.
> 
> >> +asymmetric key that is used to validate anything added to it.  This key can
> >> +be added during boot and must be a preexisting system kernel key.  If the
> >> +``clavis=`` boot parameter is not used, any asymmetric key the user owns
> > 
> > Who is "the user", and precisely what does "owns' mean here?  Is it just
> > restating that it must be a key already in one of the builtin or secondary
> > or platform keyrings?
> 
> In the case where Clavis was not provided a key id during boot, root can 
> add a single public key to the .clavis keyring anytime afterwards.  This 
> key does not need to be in any of the system keyrings.  Once the key is 
> added, the Clavis LSM is enabled. The root user must also own the private 
> key, since this is required to do the ACL signing. I will try to clarify this better 

Ooh, I see.  Own it as in be able to sign things with it.  Of course.  Thanks.

> in the documentation. 
> 
> I wouldn't expect this to be the typical way Clavis would be used. I would 

Right, I wasn't asking because I would want to use it that way, but
because it feels potentially dangerous :)

> also be interested in any feedback if enabling the Clavis LSM this way 
> following boot should be removed.  If this were removed, Clavis could 
> only be enabled when using the boot parameter.

Yeah I don't know enough to give good guidance here.  I do worry about
UKIs enforcing only the built-in signed kernel command line and so preventing
a user from appending their own clavis= entry.  Not knowing how this
will end up getting deployed, I'm not sure which is the more important
issue.

> > And this is done by simply loading it into the clavis keyring, right?
> 
> Correct.
> 

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Motivation:
> 
> Each end-user has their own security threat model. What is important to one
> end-user may not be important to another. There is not a right or wrong threat
> model.
> 
> A common request made when adding new kernel changes that could impact the
> threat model around system kernel keys is to add additional Kconfig options.
> As kernel developers, it is challenging to both add and keep track of all the
> Kconfig options around security features that may limit or restrict
> system key usage.  It is also difficult for a general purpose distro to take
> advantage of some of these features, since it may prevent some users from
> executing their workload.
> 
> It is the author's belief that it is better left up to the end-user on how
> kernel keys should be used within their system.
> 
> Throughout the Linux kernel, key usage is tracked when doing signature
> verification with keys contained within one of the system keyrings;  however,
> there isn't a way for the end-user to enforce this usage.  This series gives the
> end-user the ability to configure key usage based on their threat model.
> Having the ability to enforce key usage also improves security by reducing the
> attack surface should a system key be compromised. It allows new features to be
> added without the need for additional Kconfig options for fear of changing the
> end-user's threat model. It also allows a distro to build a kernel that suits
> various end-user's needs without resorting to selecting Kconfig options with
> the least restrictive security options.

The motivation for this patch set is convincing and addresses limiting the usage
of keys loaded directly or indirectly onto the system trusted keyrings - 
.builtin, .machine, and .secondary_trusted_keys keyrings.  Pre-loading the build
time ephemeral kernel module signing key is a nice improvement from the previous
versions.  My main concern is not with Clavis per-se, but that the LSM
infrastructure allows configuring all the LSMs, but enabling at build time and
modifying at runtime a subset of them.  Without Clavis enabled, nothing changes
- any key on the system trusted keyrings remains usable for any purpose.  With
the current LSM design, the end user security threat model cannot be guaranteed.

Mimi
> 
> Solution:
> 
> This series introduces a new LSM called Clavis (Latin word meaning key).
> This LSM leaves it up to the end-user to determine what system keys they want
> to use and for what purpose.
> 
> The Clavis LSM adds the ability to do access control for all system keys.  When
> enabled, until an ACL entry is added for a specific key, none of the system keys
> may be used for any type of verification purpose.  When the kernel is built,
> typically kernel modules are signed with an ephemeral key, an ACL entry for the
> ephemeral key is pre-loaded, allowing the kernel modules to load during boot. At
> build time other ACL entries may also be included.
> 
> The Clavis LSM requires the end-user to have their own public key infrastructure
> (PKI).  In order for a Clavis ACL entry to be added, the ACL must be signed by
> what is being called the Clavis key.  The Clavis key is owned by the end-user.
> The Clavis public key can be contained within the machine keyring, or it can be
> added after the machine boots.
> 
> Not only is there a new Clavis key being introduced, but there is also a new
> .clavis keyring.  The .clavis keyring contains a single Clavis key. It also
> contains any number of ACL entries that are signed by the Clavis key.
> 
> It is believed that the most common setup would be to have the Clavis key
> contained within the machine keyring. Enabling the Clavis LSM during boot is
> accomplished by passing in the asymmetric key id for the Clavis key within a
> new "clavis=" boot param.  The asymmetric key id must match one already
> contained within any of the system keyrings.  If a match is found, a link is
> created into the new .clavis keyring.  This Clavis key shall be used as the
> root of trust for any keyring ACL updates afterwards.
> 
> On UEFI systems the "clavis" boot param is mirrored into a new UEFI variable
> within the EFI stub code. This variable will persist until the next reboot.
> This same type of functionality is done within shim. Since this variable is
> created before ExitBootServices (EBS) it will not have the NVRAM bit set,
> signifying it was created during the Boot Services phase. This is being used
> so the "clavis" boot param can not be changed via kexec, thereby preventing a
> pivot of the root of trust.
> 
> As mentioned earlier, this LSM introduces a new .clavis keyring.  Following
> boot, no new keys can be added to this keyring and only the key designated via
> the initial boot param may be used. If the clavis boot param was not used, the
> LSM can be enabled afterwards using the keyctl command.  The end-user may add
> their Clavis key into the .clavis keyring and the Clavis LSM shall be enabled.
> 
> The .clavis keyring also holds the access control list for system keys. A new
> key type called clavis_key_acl is being introduced. This contains the usage
> followed by the asymmetric key id. To be added to the clavis keyring, the
> clavis_key_acl must be S/MIME signed by the Clavis key. New ACL additions to
> the .clavis keyring may be added at any time.
> 
> Currently this LSM does not require new changes or modifications to any user
> space tools.  It also does not have a securityfs interface.  Everything is
> done using the existing keyctl tool through the new .clavis keyring. The
> S/MIME signing can be done with a simple OpenSSL command. If additions or
> updates need to be added in the future, new ACL key types could be created.
> With this approach, maintainability should not be an issue in the future
> if missing items are identified.
> 
> Clavis must be configured at build time with CONFIG_SECURITY_CLAVIS=y. The list
> of security modules enabled by default is set with CONFIG_LSM.  The kernel
> configuration must contain CONFIG_LSM=[...],clavis with [...] as the list of
> other security modules for the running system.
> 
> For setup and usage instructions, a clavis admin-guide has been included
> in Documentation/admin-guide/LSM/clavis.rst.
> 
> Future enhancements to this LSM could include:
> 
> 1. Subsystems that currently use system keys with
>    VERIFYING_UNSPECIFIED_SIGNATURE could be updated with their specific usage
>    type.  For example, a usage type for IMA, BPF, etc could be added.
> 
> 2. Having the ability to allow platform keys to be on par with all other
>    system keys when using this LSM. This would be useful for a user that
>    controls their entire UEFI SB DB key chain and doesn't want to use MOK keys.
>    This could also potentially remove the need for the machine keyring all
>    together.
> 
> 3. Some of the Kconfig options around key usage and types could be deprecated.
> 
> I would appreciate any feedback on this approach. Thanks.
> 
> Changes in v3:
>   Rebased to 6.12-rc3
>   Added Kunit test code
>   Preload an ACL in the clavis keyring with the ephemeral module signing key
>   Preload user defined ACL data into the clavis keyring with build time data
>   Changes to the second patch recommended by Jarkko
>   Reordered patches recommended by Mimi
>   Documentation improvements recommended by Randy
> 
> Changes in v2:
>   Rebased to 6.10-rc1
>   Various cleanup in the first patch recommended by Jarkko
>   Documentation improvements recommended by Randy
>   Fixed lint warnings
>   Other cleanup
> 
> Eric Snowberg (13):
>   certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check
>   certs: Introduce ability to link to a system key
>   clavis: Introduce a new system keyring called clavis
>   keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)
>   clavis: Introduce a new key type called clavis_key_acl
>   clavis: Populate clavis keyring acl with kernel module signature
>   keys: Add ability to track intended usage of the public key
>   clavis: Introduce new LSM called clavis
>   clavis: Allow user to define acl at build time
>   efi: Make clavis boot param persist across kexec
>   clavis: Prevent boot param change during kexec
>   clavis: Add function redirection for Kunit support
>   clavis: Kunit support
> 
>  Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++
>  .../admin-guide/kernel-parameters.txt         |   6 +
>  MAINTAINERS                                   |   7 +
>  certs/.gitignore                              |   1 +
>  certs/Makefile                                |  20 +
>  certs/blacklist.c                             |   3 +
>  certs/clavis_module_acl.c                     |   7 +
>  certs/system_keyring.c                        |  36 +-
>  crypto/asymmetric_keys/asymmetric_type.c      |   1 +
>  crypto/asymmetric_keys/pkcs7_trust.c          |  20 +
>  crypto/asymmetric_keys/pkcs7_verify.c         |   5 +
>  crypto/asymmetric_keys/signature.c            |   4 +
>  drivers/firmware/efi/Kconfig                  |  12 +
>  drivers/firmware/efi/libstub/Makefile         |   1 +
>  drivers/firmware/efi/libstub/clavis.c         |  33 +
>  .../firmware/efi/libstub/efi-stub-helper.c    |   2 +
>  drivers/firmware/efi/libstub/efi-stub.c       |   2 +
>  drivers/firmware/efi/libstub/efistub.h        |   8 +
>  drivers/firmware/efi/libstub/x86-stub.c       |   2 +
>  include/crypto/pkcs7.h                        |   3 +
>  include/crypto/public_key.h                   |   4 +
>  include/keys/system_keyring.h                 |   7 +-
>  include/linux/efi.h                           |   1 +
>  include/linux/integrity.h                     |   8 +
>  include/linux/lsm_count.h                     |   8 +-
>  include/linux/lsm_hook_defs.h                 |   2 +
>  include/linux/security.h                      |   7 +
>  include/linux/verification.h                  |   2 +
>  include/uapi/linux/lsm.h                      |   1 +
>  security/Kconfig                              |  11 +-
>  security/Makefile                             |   1 +
>  security/clavis/.gitignore                    |   2 +
>  security/clavis/.kunitconfig                  |   4 +
>  security/clavis/Kconfig                       |  37 ++
>  security/clavis/Makefile                      | 156 +++++
>  security/clavis/clavis.c                      |  26 +
>  security/clavis/clavis.h                      |  62 ++
>  security/clavis/clavis_builtin_acl.c          |   7 +
>  security/clavis/clavis_efi.c                  |  50 ++
>  security/clavis/clavis_keyring.c              | 426 +++++++++++++
>  security/clavis/clavis_test.c                 | 566 ++++++++++++++++++
>  security/integrity/iint.c                     |   2 +
>  security/security.c                           |  13 +
>  .../selftests/lsm/lsm_list_modules_test.c     |   3 +
>  44 files changed, 1757 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/admin-guide/LSM/clavis.rst
>  create mode 100644 certs/clavis_module_acl.c
>  create mode 100644 drivers/firmware/efi/libstub/clavis.c
>  create mode 100644 security/clavis/.gitignore
>  create mode 100644 security/clavis/.kunitconfig
>  create mode 100644 security/clavis/Kconfig
>  create mode 100644 security/clavis/Makefile
>  create mode 100644 security/clavis/clavis.c
>  create mode 100644 security/clavis/clavis.h
>  create mode 100644 security/clavis/clavis_builtin_acl.c
>  create mode 100644 security/clavis/clavis_efi.c
>  create mode 100644 security/clavis/clavis_keyring.c
>  create mode 100644 security/clavis/clavis_test.c
> 
> 
> base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354

Re: [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check

[Mimi Zohar]

Hi Eric,

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this
> pattern does not need to be repeated with new code.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Ok. The reason why testing the Kconfig is unnecessary should be included in the
patch description.  For example,

Commit 219a3e8676f3 ("integrity, KEYS: add a reference to platform keyring")
unnecessarily added the Kconfig test.  As platform_trusted_keys is already
initialized, simply use it.

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

> ---
>  certs/system_keyring.c | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index 9de610bf1f4b..e344cee10d28 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys;
>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
>  static struct key *machine_trusted_keys;
>  #endif
> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
>  static struct key *platform_trusted_keys;
> -#endif
>  
>  extern __initconst const u8 system_certificate_list[];
>  extern __initconst const unsigned long system_certificate_list_size;
> @@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
>  		trusted_keys = builtin_trusted_keys;
>  #endif
>  	} else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) {
> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
>  		trusted_keys = platform_trusted_keys;
> -#else
> -		trusted_keys = NULL;
> -#endif
>  		if (!trusted_keys) {
>  			ret = -ENOKEY;
>  			pr_devel("PKCS#7 platform keyring is not available\n");

Re: [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key

[Mimi Zohar]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Introduce system_key_link(), a new function to allow a keyring to link
> to a key contained within one of the system keyrings (builtin, secondary,
> or platform). Depending on how the kernel is built, if the machine
> keyring is available, it will be checked as well, since it is linked to
> the secondary keyring. If the asymmetric key id matches a key within one
> of these system keyrings, the matching key is linked into the passed in
> keyring.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

> ---
>  certs/system_keyring.c        | 30 ++++++++++++++++++++++++++++++
>  include/keys/system_keyring.h |  7 ++++++-
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/certs/system_keyring.c b/certs/system_keyring.c
> index e344cee10d28..4abee7514442 100644
> --- a/certs/system_keyring.c
> +++ b/certs/system_keyring.c
> @@ -20,6 +20,9 @@
>  static struct key *builtin_trusted_keys;
>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
>  static struct key *secondary_trusted_keys;
> +#define system_trusted_keys secondary_trusted_keys
> +#else
> +#define system_trusted_keys builtin_trusted_keys
>  #endif
>  #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
>  static struct key *machine_trusted_keys;
> @@ -420,3 +423,30 @@ void __init set_platform_trusted_keys(struct key *keyring)
>  	platform_trusted_keys = keyring;
>  }
>  #endif
> +
> +/**
> + * system_key_link - Link to a system key
> + * @keyring: The keyring to link into
> + * @id: The asymmetric key id to look for in the system keyring
> + *
> + * Search the system keyrings to see if one of them contains a matching "id".
> + * If there is a match, link the key into "keyring".  System keyrings always
> + * includes the builtin. If any of the following keyrings are enabled:
> + * secondary, machine, and platform they are searched as well.
> + */
> +int system_key_link(struct key *keyring, struct asymmetric_key_id *id)
> +{
> +	struct key *key;
> +
> +	key = find_asymmetric_key(system_trusted_keys, id, NULL, NULL, false);
> +	if (!IS_ERR(key))
> +		return key_link(keyring, key);
> +
> +	if (platform_trusted_keys) {
> +		key = find_asymmetric_key(platform_trusted_keys, id, NULL, NULL, false);
> +		if (!IS_ERR(key))
> +			return key_link(keyring, key);
> +	}
> +
> +	return -ENOKEY;
> +}
> diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> index 8365adf842ef..b47ac8e2001a 100644
> --- a/include/keys/system_keyring.h
> +++ b/include/keys/system_keyring.h
> @@ -9,6 +9,7 @@
>  #define _KEYS_SYSTEM_KEYRING_H
>  
>  #include <linux/key.h>
> +struct asymmetric_key_id;
>  
>  enum blacklist_hash_type {
>  	/* TBSCertificate hash */
> @@ -28,7 +29,7 @@ int restrict_link_by_digsig_builtin(struct key *dest_keyring,
>  				    const union key_payload *payload,
>  				    struct key *restriction_key);
>  extern __init int load_module_cert(struct key *keyring);
> -
> +extern int system_key_link(struct key *keyring, struct asymmetric_key_id *id);
>  #else
>  #define restrict_link_by_builtin_trusted restrict_link_reject
>  #define restrict_link_by_digsig_builtin restrict_link_reject
> @@ -38,6 +39,10 @@ static inline __init int load_module_cert(struct key *keyring)
>  	return 0;
>  }
>  
> +static inline int system_key_link(struct key *keyring, struct asymmetric_key_id *id)
> +{
> +	return 0;
> +}
>  #endif
>  
>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING

Re: [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Mimi Zohar]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Introduce a new system keyring called clavis.  This keyring shall contain
> a single asymmetric key. This key may be a linked to a key already
> contained in one of the system keyrings (builtin, secondary, or platform).

Although "This key may be a linked to ..." is might be correct.  Being
introduced in this patch is only the ability of loading a key by specifying it
on the boot command line.  In this case, the key must be on one of the system
keyrings.

> One way to add this key into this keyring is during boot by passing in the
> asymmetric key id within the new "clavis=" boot param.  If a matching key
> is found in one of the system keyrings, a link shall be created. This
> keyring will be used in the future by the new Clavis LSM.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  .../admin-guide/kernel-parameters.txt         |   6 +
>  include/linux/integrity.h                     |   8 ++
>  security/Kconfig                              |   1 +
>  security/Makefile                             |   1 +
>  security/clavis/Kconfig                       |  11 ++
>  security/clavis/Makefile                      |   3 +
>  security/clavis/clavis.h                      |  13 ++
>  security/clavis/clavis_keyring.c              | 115 ++++++++++++++++++
>  security/integrity/iint.c                     |   2 +
>  9 files changed, 160 insertions(+)
>  create mode 100644 security/clavis/Kconfig
>  create mode 100644 security/clavis/Makefile
>  create mode 100644 security/clavis/clavis.h
>  create mode 100644 security/clavis/clavis_keyring.c
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1518343bbe22..d71397e7d254 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -645,6 +645,12 @@
>  	cio_ignore=	[S390]
>  			See Documentation/arch/s390/common_io.rst for details.
>  
> +	clavis=		[SECURITY,EARLY]
> +			Identifies a specific key contained in one of the system
> +			keyrings (builtin, secondary, or platform) to be used as
> +			the Clavis root of trust.
> +			Format: { <keyid> }

Include .machine keyring here.

> +
>  	clearcpuid=X[,X...] [X86]
>  			Disable CPUID feature X for the kernel. See
>  			arch/x86/include/asm/cpufeatures.h for the valid bit
> diff --git a/include/linux/integrity.h b/include/linux/integrity.h
> index f5842372359b..837c52e1d83b 100644
> --- a/include/linux/integrity.h
> +++ b/include/linux/integrity.h
> @@ -23,6 +23,14 @@ enum integrity_status {
>  #ifdef CONFIG_INTEGRITY
>  extern void __init integrity_load_keys(void);
>  
> +#ifdef CONFIG_SECURITY_CLAVIS
> +void __init late_init_clavis_setup(void);
> +#else
> +static inline void late_init_clavis_setup(void)
> +{
> +}
> +#endif
> +
>  #else
>  static inline void integrity_load_keys(void)
>  {
> diff --git a/security/Kconfig b/security/Kconfig
> index 28e685f53bd1..714ec08dda96 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -225,6 +225,7 @@ source "security/safesetid/Kconfig"
>  source "security/lockdown/Kconfig"
>  source "security/landlock/Kconfig"
>  source "security/ipe/Kconfig"
> +source "security/clavis/Kconfig"
>  
>  source "security/integrity/Kconfig"
>  
> diff --git a/security/Makefile b/security/Makefile
> index cc0982214b84..69576551007a 100644
> --- a/security/Makefile
> +++ b/security/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_CGROUPS)			+= device_cgroup.o
>  obj-$(CONFIG_BPF_LSM)			+= bpf/
>  obj-$(CONFIG_SECURITY_LANDLOCK)		+= landlock/
>  obj-$(CONFIG_SECURITY_IPE)		+= ipe/
> +obj-$(CONFIG_SECURITY_CLAVIS)		+= clavis/
>  
>  # Object integrity file lists
>  obj-$(CONFIG_INTEGRITY)			+= integrity/
> diff --git a/security/clavis/Kconfig b/security/clavis/Kconfig
> new file mode 100644
> index 000000000000..04f7565f2e2b
> --- /dev/null
> +++ b/security/clavis/Kconfig
> @@ -0,0 +1,11 @@
> +config SECURITY_CLAVIS
> +	bool "Clavis keyring"

Isn't SECURITY_CLAVIS the new LSM?  Why is the bool defined as just "Clavis
keyring"?

> +	depends on SECURITY
> +	select SYSTEM_DATA_VERIFICATION
> +	select CRYPTO_SHA256
> +	help
> +	  Enable the clavis keyring. This keyring shall contain a single asymmetric key.
> +	  This key shall be linked to a key already contained in one of the system
> +	  keyrings (builtin, secondary, or platform). One way to add this key
> +	  is during boot by passing in the asymmetric key id within the "clavis=" boot
> +	  param.  This keyring is required by the Clavis LSM.

If SECURITY_CLAVIS is a new LSM, the 'help' shouldn't be limited to just the
clavis keyring, but written at a higher level describing the new LSM.  For
example,

This option enables the Clavis LSM, which provides the ability to configure and
enforce the usage of keys contained on the system keyrings -
.builtin_trusted_keys, .secondary_trusted_keys, .machine, and .platform
keyrings.  The clavis LSM defines a keyring named "clavis", which contains a
single asymmetric key and the key usage rules.

The single asymmetric key may be specified on the boot command line ...

[The patch that introduces the key usage rules would add additional info here.]

[The patch that adds the Documentatoin would add a reference here.]

> diff --git a/security/clavis/Makefile b/security/clavis/Makefile
> new file mode 100644
> index 000000000000..16c451f45f37
> --- /dev/null
> +++ b/security/clavis/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
> diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
> new file mode 100644
> index 000000000000..5e397b55a60a
> --- /dev/null
> +++ b/security/clavis/clavis.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _SECURITY_CLAVIS_H_
> +#define _SECURITY_CLAVIS_H_
> +#include <keys/asymmetric-type.h>
> +
> +/* Max length for the asymmetric key id contained on the boot param */
> +#define CLAVIS_BIN_KID_MAX   32
> +
> +struct asymmetric_setup_kid {
> +	struct asymmetric_key_id id;
> +	unsigned char data[CLAVIS_BIN_KID_MAX];
> +};
> +#endif /* _SECURITY_CLAVIS_H_ */
> diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
> new file mode 100644
> index 000000000000..400ed455a3a2
> --- /dev/null
> +++ b/security/clavis/clavis_keyring.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/security.h>
> +#include <linux/integrity.h>
> +#include <keys/asymmetric-type.h>
> +#include <keys/system_keyring.h>
> +#include "clavis.h"
> +
> +static struct key *clavis_keyring;
> +static struct asymmetric_key_id *clavis_boot_akid;
> +static struct asymmetric_setup_kid clavis_setup_akid;
> +static bool clavis_enforced;
> +
> +static bool clavis_acl_enforced(void)
> +{
> +	return clavis_enforced;
> +}

Add blank line between functions.

Mimi

> +static int restrict_link_for_clavis(struct key *dest_keyring, const struct key_type *type,
> +				    const union key_payload *payload, struct key *restrict_key)
> +{
> +	/*
> +	 * Allow a single asymmetric key into this keyring. This key is used as the
> +	 * root of trust for anything added afterwards.
> +	 */
> +	if (type == &key_type_asymmetric && dest_keyring == clavis_keyring &&
> +	    !clavis_acl_enforced()) {
> +		clavis_enforced = true;
> +		return 0;
> +	}
> +
> +	return -EOPNOTSUPP;
> +}
> +
> +static struct asymmetric_key_id *clavis_parse_boot_param(char *kid, struct asymmetric_key_id *akid,
> +							 int akid_max_len)
> +{
> +	int error, hex_len;
> +
> +	if (!kid)
> +		return 0;
> +
> +	hex_len = strlen(kid) / 2;
> +
> +	if (hex_len > akid_max_len)
> +		return 0;
> +
> +	akid->len = hex_len;
> +	error = hex2bin(akid->data, kid, akid->len);
> +
> +	if (error < 0) {
> +		pr_err("Unparsable clavis key id\n");
> +		return 0;
> +	}
> +
> +	return akid;
> +}
> +
> +static int __init clavis_param(char *kid)
> +{
> +	clavis_boot_akid = clavis_parse_boot_param(kid, &clavis_setup_akid.id,
> +						   ARRAY_SIZE(clavis_setup_akid.data));
> +
> +	return 1;
> +}
> +
> +__setup("clavis=", clavis_param);
> +
> +static struct key *clavis_keyring_alloc(const char *desc, struct key_restriction *restriction)
> +{
> +	struct key *keyring;
> +
> +	keyring = keyring_alloc(desc, GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
> +				KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH | KEY_POS_WRITE |
> +				KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH | KEY_USR_WRITE,
> +				KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP,
> +				restriction, NULL);
> +	return keyring;
> +}
> +
> +static struct key_restriction *clavis_restriction_alloc(key_restrict_link_func_t check_func)
> +{
> +	struct key_restriction *restriction;
> +
> +	restriction = kzalloc(sizeof(*restriction), GFP_KERNEL);
> +
> +	if (restriction)
> +		restriction->check = check_func;
> +
> +	return restriction;
> +}
> +
> +static int __init clavis_keyring_init(void)
> +{
> +	struct key_restriction *restriction;
> +
> +	restriction = clavis_restriction_alloc(restrict_link_for_clavis);
> +	if (!restriction)
> +		panic("Can't allocate clavis keyring restriction\n");
> +
> +	clavis_keyring = clavis_keyring_alloc(".clavis", restriction);
> +	if (IS_ERR(clavis_keyring))
> +		panic("Can't allocate clavis keyring\n");
> +
> +	return 0;
> +}
> +
> +void __init late_init_clavis_setup(void)
> +{
> +	clavis_keyring_init();
> +
> +	if (!clavis_boot_akid)
> +		return;
> +
> +	system_key_link(clavis_keyring, clavis_boot_akid);
> +}
> diff --git a/security/integrity/iint.c b/security/integrity/iint.c
> index 068ac6c2ae1e..87a8bfc0662f 100644
> --- a/security/integrity/iint.c
> +++ b/security/integrity/iint.c
> @@ -36,6 +36,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
>   */
>  void __init integrity_load_keys(void)
>  {
> +	late_init_clavis_setup();
> +
>  	ima_load_x509();
>  
>  	if (!IS_ENABLED(CONFIG_IMA_LOAD_X509))

Re: [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)

[Mimi Zohar]

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:

Add "fallthrough;"

https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through


>  	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];

Re: [RFC PATCH v3 13/13] clavis: Kunit support

[Mimi Zohar]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> +config SECURITY_CLAVIS_KUNIT_TEST
> +	bool "KUnit tests for Clavis" if !KUNIT_ALL_TESTS
> +	depends on SECURITY_CLAVIS && KUNIT

Change KUNIT -> KUNIT=y

> +	default KUNIT_ALL_TESTS
> +	select SYSTEM_BLACKLIST_KEYRING
> +	select SYSTEM_REVOCATION_LIST
> +	help
> +	  Build KUnit tests for Clavis.
> +
> +	  See the KUnit documentation in Documentation/dev-tools/kunit
> +
> +	  Run all KUnit tests for Clavis with:
> +	  ./tools/testing/kunit/kunit.py run --kunitconfig security/clavis
> +
> +	  If you are unsure how to answer this question, answer N.

thanks,

Mimi

Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[Mimi Zohar]

On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> Introduce a new LSM called clavis.  The motivation behind this LSM is to
> provide access control for system keys.  The access control list is
> contained within a keyring call .clavis.  During boot if the clavis= boot
> arg is supplied with a key id contained within any of the current system
> keyrings (builtin, secondary, machine, or platform) it shall be used as
> the root of trust for validating anything that is added to the ACL list.
> 
> The first restriction introduced with this LSM is the ability to enforce
> key usage.  The kernel already has a notion of tracking key usage.  This
> LSM adds the ability to enforce this usage based on the system owners
> configuration.
> 
> Each system key may have one or more uses defined within the ACL list.
> Until an entry is added to the .clavis keyring, no other system key may
> be used for any other purpose.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> ---
>  Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++++++++++++++
>  MAINTAINERS                                   |   7 +
>  crypto/asymmetric_keys/signature.c            |   4 +
>  include/linux/lsm_count.h                     |   8 +-
>  include/linux/lsm_hook_defs.h                 |   2 +
>  include/linux/security.h                      |   7 +
>  include/uapi/linux/lsm.h                      |   1 +
>  security/Kconfig                              |  10 +-
>  security/clavis/Makefile                      |   1 +
>  security/clavis/clavis.c                      |  26 +++
>  security/clavis/clavis.h                      |   4 +
>  security/clavis/clavis_keyring.c              |  78 ++++++-
>  security/security.c                           |  13 ++
>  .../selftests/lsm/lsm_list_modules_test.c     |   3 +
>  14 files changed, 346 insertions(+), 9 deletions(-)
>  create mode 100644 Documentation/admin-guide/LSM/clavis.rst
>  create mode 100644 security/clavis/clavis.c
> 
> diff --git a/Documentation/admin-guide/LSM/clavis.rst b/Documentation/admin-guide/LSM/clavis.rst
> new file mode 100644
> index 000000000000..0e924f638a86
> --- /dev/null
> +++ b/Documentation/admin-guide/LSM/clavis.rst
> @@ -0,0 +1,191 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +======
> +Clavis
> +======
> +
> +Clavis is a Linux Security Module that provides mandatory access control to
> +system kernel keys (i.e. builtin, secondary, machine and platform). These
> +restrictions will prohibit keys from being used for validation. Upon boot, the
> +Clavis LSM is provided a key id as a boot parameter.  This single key is then
> +used as the root of trust for any access control modifications made going
> +forward. Access control updates must be signed and validated by this key.
> +
> +Clavis has its own keyring.  All ACL updates are applied through this keyring.
> +The update must be signed by the single root of trust key.
> +
> +When enabled, all system keys are prohibited from being used until an ACL is
> +added for them.

Until the single key has been loaded, Clavis is not enabled.  Any key on the
system trusted keyrings remains usable for any purpose.

-> When enabled, meaning the single key has been loaded onto the Clavis keyring,
all system keys are prohibited ...

Until clavis is enabled, in my opinion the defaults should be restrictive (e.g.
CONFIG_INTEGRITY_CA_MACHINE_KEYRING,
CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN). Once Clavis is enabled,
based on a new helper function is_clavis_enforced() we could consider relaxing
some of the existing keyring requirements (e.g. kernel modules).

Mimi

> +
> +On UEFI platforms, the root of trust key shall survive a kexec. Trying to
> +defeat or change it from the command line is not allowed.  The original boot
> +parameter is stored in UEFI and will always be referenced following a kexec.
> +
> +The Clavis LSM contains a system keyring call .clavis.  It contains a single
> +asymmetric key that is used to validate anything added to it.  This key can
> +be added during boot and must be a preexisting system kernel key.  If the
> +``clavis=`` boot parameter is not used, any asymmetric key the user owns
> +can be added to enable the LSM.
> +
> +The only user space components are OpenSSL and the keyctl utility. A new
> +key type call ``clavis_key_acl`` is used for ACL updates. Any number of signed
> +``clavis_key_acl`` entries may be added to the .clavis keyring. The
> +``clavis_key_acl`` contains the subject key identifier along with the allowed
> +usage type for the key.
> +
> +The format is as follows:
> +
> +.. code-block:: console
> +
> +  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
> +
> +The ``clavis_key_acl`` must be S/MIME signed by the sole asymmetric key contained
> +within the .clavis keyring.
> +
> +In the future if new features are added, new key types could be created.
> +
> +Usage Examples
> +==============
> +
> +How to create a signing key:
> +----------------------------
> +
> +.. code-block:: bash
> +
> +  cat <<EOF > clavis-lsm.genkey
> +  [ req ]
> +  default_bits = 4096
> +  distinguished_name = req_distinguished_name
> +  prompt = no
> +  string_mask = utf8only
> +  x509_extensions = v3_ca
> +  [ req_distinguished_name ]
> +  O = TEST
> +  CN = Clavis LSM key
> +  emailAddress = user@example.com
> +  [ v3_ca ]
> +  basicConstraints=CA:TRUE
> +  subjectKeyIdentifier=hash
> +  authorityKeyIdentifier=keyid:always,issuer
> +  keyUsage=digitalSignature
> +  EOF
> +
> +  openssl req -new -x509 -utf8 -sha256 -days 3650 -batch \
> +        -config clavis-lsm.genkey -outform DER \
> +        -out clavis-lsm.x509 -keyout clavis-lsm.priv
> +
> +How to get the Subject Key Identifier
> +-------------------------------------
> +
> +.. code-block:: bash
> +
> +  openssl x509 -in ./clavis-lsm.x509 -inform der \
> +        -ext subjectKeyIdentifier  -nocert \
> +        | tail -n +2 | cut -f2 -d '='| tr -d ':'
> +  4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
> +
> +How to enroll the signing key into the MOK
> +------------------------------------------
> +
> +The key must now be added to the machine or platform keyrings.  This
> +indicates the key was added by the system owner. For kernels booted through
> +shim, a first-stage UEFI boot loader, a key may be added to the machine keyring
> +by doing:
> +
> +.. code-block:: bash
> +
> +  mokutil --import ./clavis-lsm.x509
> +
> +and then rebooting and enrolling the key through MokManager.
> +
> +How to enable the Clavis LSM
> +----------------------------
> +
> +Add the key id to the ``clavis=`` boot parameter.  With the example above the
> +key id is the subject key identifier: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
> +
> +Add the following boot parameter:
> +
> +.. code-block:: console
> +
> +  clavis=4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
> +
> +After booting there will be a single key contained in the .clavis keyring:
> +
> +.. code-block:: bash
> +
> +  keyctl show %:.clavis
> +  Keyring
> +    254954913 ----swrv      0     0  keyring: .clavis
> +    301905375 ---lswrv      0     0   \_ asymmetric: TEST: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
> +
> +The original ``clavis=`` boot parameter will persist across any kexec. Changing it or
> +removing it has no effect.
> +
> +
> +How to sign an entry to be added to the .clavis keyring:
> +--------------------------------------------------------
> +
> +In this example we have 3 keys in the machine keyring.  Our Clavis LSM key, a
> +key we want to use for kernel verification and a key we want to use for module
> +verification.
> +
> +.. code-block:: bash
> +
> +  keyctl show %:.machine
> +  Keyring
> +    999488265 ---lswrv      0     0  keyring: .machine
> +    912608009 ---lswrv      0     0   \_ asymmetric: TEST: Module Key: 17eb8c5bf766364be094c577625213700add9471
> +    646229664 ---lswrv      0     0   \_ asymmetric: TEST: Kernel Key: b360d113c848ace3f1e6a80060b43d1206f0487d
> +   1073737099 ---lswrv      0     0   \_ asymmetric: TEST: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
> +
> +To update the .clavis kerying ACL list, first create a file containing the
> +key usage type followed by a colon and the key id that we want to allow to
> +validate that usage.  In the first example we are saying key
> +17eb8c5bf766364be094c577625213700add9471 is allowed to validate kernel modules.
> +In the second example we are saying key b360d113c848ace3f1e6a80060b43d1206f0487d
> +is allowed to validate signed kernels.
> +
> +.. code-block:: bash
> +
> +  echo "00:17eb8c5bf766364be094c577625213700add9471" > module-acl.txt
> +  echo "02:b360d113c848ace3f1e6a80060b43d1206f0487d" > kernel-acl.txt
> +
> +Now both these files must be signed by the key contained in the .clavis keyring:
> +
> +.. code-block:: bash
> +
> +  openssl smime -sign -signer clavis-lsm.x509 -inkey clavis-lsm.priv -in module-acl.txt \
> +        -out module-acl.pkcs7 -binary -outform DER -nodetach -noattr
> +
> +  openssl smime -sign -signer clavis-lsm.x509 -inkey clavis-lsm.priv -in kernel-acl.txt \
> +        -out kernel-acl.pkcs7 -binary -outform DER -nodetach -noattr
> +
> +Afterwards the ACL list in the clavis keyring can be updated:
> +
> +.. code-block:: bash
> +
> +  keyctl padd clavis_key_acl "" %:.clavis < module-acl.pkcs7
> +  keyctl padd clavis_key_acl "" %:.clavis < kernel-acl.pkcs7
> +
> +  keyctl show %:.clavis
> +
> +  Keyring
> +    254954913 ----swrv      0     0  keyring: .clavis
> +    301905375 ---lswrv      0     0   \_ asymmetric: TEST: Clavis LSM key: 4a00ab9f35c9dc3aed7c225d22bafcbd9285e1e8
> +   1013065475 --alswrv      0     0   \_ clavis_key_acl: 02:b360d113c848ace3f1e6a80060b43d1206f0487d
> +    445581284 --alswrv      0     0   \_ clavis_key_acl: 00:17eb8c5bf766364be094c577625213700add9471
> +
> +Now the 17eb8c5bf766364be094c577625213700add9471 key can be used for
> +validating kernel modules and the b360d113c848ace3f1e6a80060b43d1206f0487d
> +key can be used to validate signed kernels.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7ad507f49324..748ba3f1143e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5567,6 +5567,13 @@ F:	scripts/Makefile.clang
>  F:	scripts/clang-tools/
>  K:	\b(?i:clang|llvm)\b
>  
> +CLAVIS LINUX SECURITY MODULE
> +M:	Eric Snowberg <eric.snowberg@oracle.com>
> +L:	linux-security-module@vger.kernel.org
> +S:	Maintained
> +F:	Documentation/admin-guide/LSM/clavis.rst
> +F:	security/clavis
> +
>  CLK API
>  M:	Russell King <linux@armlinux.org.uk>
>  L:	linux-clk@vger.kernel.org
> diff --git a/crypto/asymmetric_keys/signature.c b/crypto/asymmetric_keys/signature.c
> index 2deff81f8af5..7e3a78650a93 100644
> --- a/crypto/asymmetric_keys/signature.c
> +++ b/crypto/asymmetric_keys/signature.c
> @@ -13,6 +13,7 @@
>  #include <linux/err.h>
>  #include <linux/slab.h>
>  #include <linux/keyctl.h>
> +#include <linux/security.h>
>  #include <crypto/public_key.h>
>  #include <keys/user-type.h>
>  #include "asymmetric_keys.h"
> @@ -153,6 +154,9 @@ int verify_signature(const struct key *key,
>  
>  	ret = subtype->verify_signature(key, sig);
>  
> +	if (!ret)
> +		ret = security_key_verify_signature(key, sig);
> +
>  	pr_devel("<==%s() = %d\n", __func__, ret);
>  	return ret;
>  }
> diff --git a/include/linux/lsm_count.h b/include/linux/lsm_count.h
> index 16eb49761b25..146aba3993d9 100644
> --- a/include/linux/lsm_count.h
> +++ b/include/linux/lsm_count.h
> @@ -102,6 +102,11 @@
>  #define IPE_ENABLED
>  #endif
>  
> +#if IS_ENABLED(CONFIG_SECURITY_CLAVIS)
> +#define CLAVIS_ENABLED 1,
> +#else
> +#define CLAVIS_ENABLED
> +#endif
>  /*
>   *  There is a trailing comma that we need to be accounted for. This is done by
>   *  using a skipped argument in __COUNT_LSMS
> @@ -124,7 +129,8 @@
>  		LANDLOCK_ENABLED	\
>  		IMA_ENABLED		\
>  		EVM_ENABLED		\
> -		IPE_ENABLED)
> +		IPE_ENABLED		\
> +		CLAVIS_ENABLED)
>  
>  #else
>  
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index 9eca013aa5e1..a405122a4657 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -410,6 +410,8 @@ LSM_HOOK(int, 0, key_getsecurity, struct key *key, char **buffer)
>  LSM_HOOK(void, LSM_RET_VOID, key_post_create_or_update, struct key *keyring,
>  	 struct key *key, const void *payload, size_t payload_len,
>  	 unsigned long flags, bool create)
> +LSM_HOOK(int, 0, key_verify_signature, const struct key *key,
> +	 const struct public_key_signature *sig)
>  #endif /* CONFIG_KEYS */
>  
>  #ifdef CONFIG_AUDIT
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 2ec8f3014757..4439be172a51 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -63,6 +63,7 @@ enum fs_value_type;
>  struct watch;
>  struct watch_notification;
>  struct lsm_ctx;
> +struct public_key_signature;
>  
>  /* Default (no) options for the capable function */
>  #define CAP_OPT_NONE 0x0
> @@ -2053,6 +2054,7 @@ void security_key_post_create_or_update(struct key *keyring, struct key *key,
>  					const void *payload, size_t payload_len,
>  					unsigned long flags, bool create);
>  
> +int security_key_verify_signature(const struct key *key, const struct public_key_signature *sig);
>  #else
>  
>  static inline int security_key_alloc(struct key *key,
> @@ -2087,6 +2089,11 @@ static inline void security_key_post_create_or_update(struct key *keyring,
>  						      bool create)
>  { }
>  
> +static inline int security_key_verify_signature(const struct key *key,
> +						const struct public_key_signature *sig)
> +{
> +	return 0;
> +}
>  #endif
>  #endif /* CONFIG_KEYS */
>  
> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> index 938593dfd5da..a2ef13c71143 100644
> --- a/include/uapi/linux/lsm.h
> +++ b/include/uapi/linux/lsm.h
> @@ -65,6 +65,7 @@ struct lsm_ctx {
>  #define LSM_ID_IMA		111
>  #define LSM_ID_EVM		112
>  #define LSM_ID_IPE		113
> +#define LSM_ID_CLAVIS		114
>  
>  /*
>   * LSM_ATTR_XXX definitions identify different LSM attributes
> diff --git a/security/Kconfig b/security/Kconfig
> index 714ec08dda96..90355ddec5c0 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -265,11 +265,11 @@ endchoice
>  
>  config LSM
>  	string "Ordered list of enabled LSMs"
> -	default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,ipe,bpf" if DEFAULT_SECURITY_SMACK
> -	default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,ipe,bpf" if DEFAULT_SECURITY_APPARMOR
> -	default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,ipe,bpf" if DEFAULT_SECURITY_TOMOYO
> -	default "landlock,lockdown,yama,loadpin,safesetid,ipe,bpf" if DEFAULT_SECURITY_DAC
> -	default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf"
> +	default "landlock,lockdown,yama,loadpin,safesetid,smack,selinux,tomoyo,apparmor,ipe,bpf,clavis" if DEFAULT_SECURITY_SMACK
> +	default "landlock,lockdown,yama,loadpin,safesetid,apparmor,selinux,smack,tomoyo,ipe,bpf,clavis" if DEFAULT_SECURITY_APPARMOR
> +	default "landlock,lockdown,yama,loadpin,safesetid,tomoyo,ipe,bpf,clavis" if DEFAULT_SECURITY_TOMOYO
> +	default "landlock,lockdown,yama,loadpin,safesetid,ipe,bpf,clavis" if DEFAULT_SECURITY_DAC
> +	default "landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf,clavis"
>  	help
>  	  A comma-separated list of LSMs, in initialization order.
>  	  Any LSMs left off this list, except for those with order
> diff --git a/security/clavis/Makefile b/security/clavis/Makefile
> index 16c451f45f37..a3430dd6bdf9 100644
> --- a/security/clavis/Makefile
> +++ b/security/clavis/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
> +obj-$(CONFIG_SECURITY_CLAVIS) += clavis.o
> diff --git a/security/clavis/clavis.c b/security/clavis/clavis.c
> new file mode 100644
> index 000000000000..21ade9e625dc
> --- /dev/null
> +++ b/security/clavis/clavis.c
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +#include <linux/lsm_hooks.h>
> +#include <uapi/linux/lsm.h>
> +#include "clavis.h"
> +
> +static struct security_hook_list clavis_hooks[] __ro_after_init = {
> +	LSM_HOOK_INIT(key_verify_signature, clavis_sig_verify),
> +};
> +
> +const struct lsm_id clavis_lsmid = {
> +	.name = "clavis",
> +	.id = LSM_ID_CLAVIS,
> +};
> +
> +static int __init clavis_lsm_init(void)
> +{
> +	clavis_keyring_init();
> +	security_add_hooks(clavis_hooks, ARRAY_SIZE(clavis_hooks), &clavis_lsmid);
> +	return 0;
> +};
> +
> +DEFINE_LSM(clavis) = {
> +	.name = "clavis",
> +	.init = clavis_lsm_init,
> +};
> diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
> index 92f77a1939ad..b77e4ec8edbe 100644
> --- a/security/clavis/clavis.h
> +++ b/security/clavis/clavis.h
> @@ -3,6 +3,8 @@
>  #define _SECURITY_CLAVIS_H_
>  #include <keys/asymmetric-type.h>
>  
> +struct public_key_signature;
> +
>  /* Max length for the asymmetric key id contained on the boot param */
>  #define CLAVIS_BIN_KID_MAX   32
>  #define CLAVIS_ASCII_KID_MAX 64
> @@ -20,4 +22,6 @@ const char __initconst *const clavis_module_acl[] = {
>  extern const char __initconst *const clavis_module_acl[];
>  #endif
>  
> +int __init clavis_keyring_init(void);
> +int clavis_sig_verify(const struct key *key, const struct public_key_signature *sig);
>  #endif /* _SECURITY_CLAVIS_H_ */
> diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
> index 2a18d0e77189..1e1fbb54f6be 100644
> --- a/security/clavis/clavis_keyring.c
> +++ b/security/clavis/clavis_keyring.c
> @@ -284,7 +284,7 @@ static void clavis_add_acl(const char *const *skid_list, struct key *keyring)
>  	}
>  }
>  
> -static int __init clavis_keyring_init(void)
> +int __init clavis_keyring_init(void)
>  {
>  	struct key_restriction *restriction;
>  
> @@ -306,10 +306,82 @@ static int __init clavis_keyring_init(void)
>  
>  void __init late_init_clavis_setup(void)
>  {
> -	clavis_keyring_init();
> -
>  	if (!clavis_boot_akid)
>  		return;
>  
>  	system_key_link(clavis_keyring, clavis_boot_akid);
>  }
> +
> +int clavis_sig_verify(const struct key *key, const struct public_key_signature *sig)
> +{
> +	const struct asymmetric_key_ids *kids = asymmetric_key_ids(key);
> +	const struct asymmetric_key_subtype *subtype;
> +	const struct asymmetric_key_id *newkid;
> +	char *buf_ptr, *ptr;
> +	key_ref_t ref;
> +	int i, buf_len;
> +
> +	if (!clavis_acl_enforced())
> +		return 0;
> +	if (key->type != &key_type_asymmetric)
> +		return -EKEYREJECTED;
> +	subtype = asymmetric_key_subtype(key);
> +	if (!subtype || !key->payload.data[0])
> +		return -EKEYREJECTED;
> +	if (!subtype->verify_signature)
> +		return -EKEYREJECTED;
> +
> +	/* Allow sig validation when not using a system keyring */
> +	if (!test_bit(PKS_USAGE_SET, &sig->usage_flags))
> +		return 0;
> +
> +	/* The previous sig validation is enough to get on the clavis keyring */
> +	if (sig->usage == VERIFYING_CLAVIS_SIGNATURE)
> +		return 0;
> +
> +	if (test_bit(PKS_REVOCATION_PASS, &sig->usage_flags))
> +		return 0;
> +
> +	for (i = 0, buf_len = 0; i < 3; i++) {
> +		if (kids->id[i]) {
> +			newkid = (struct asymmetric_key_id *)kids->id[i];
> +			if (newkid->len > buf_len)
> +				buf_len = newkid->len;
> +		}
> +	}
> +
> +	if (!buf_len)
> +		return -EKEYREJECTED;
> +
> +	/* Allocate enough space for the conversion to ascii plus the header. */
> +	buf_ptr = kmalloc(buf_len * 2 + 4, GFP_KERNEL | __GFP_ZERO);
> +
> +	if (!buf_ptr)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < 3; i++) {
> +		if (kids->id[i]) {
> +			newkid = (struct asymmetric_key_id *)kids->id[i];
> +			if (!newkid->len)
> +				continue;
> +
> +			ptr = buf_ptr;
> +			ptr = bin2hex(ptr, &sig->usage, 1);
> +			*ptr++ = ':';
> +			ptr = bin2hex(ptr, newkid->data, newkid->len);
> +			*ptr = 0;
> +			ref = keyring_search(make_key_ref(clavis_keyring_get(), true),
> +					     &clavis_key_acl, buf_ptr, false);
> +
> +			if (!IS_ERR(ref))
> +				break;
> +		}
> +	}
> +
> +	kfree(buf_ptr);
> +
> +	if (IS_ERR(ref))
> +		return -EKEYREJECTED;
> +
> +	return 0;
> +}
> diff --git a/security/security.c b/security/security.c
> index c5981e558bc2..097f8cedcd36 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -5522,6 +5522,19 @@ void security_key_post_create_or_update(struct key *keyring, struct key *key,
>  	call_void_hook(key_post_create_or_update, keyring, key, payload,
>  		       payload_len, flags, create);
>  }
> +
> +/**
> + * security_key_verify_signature - verify signature
> + * @key: key
> + * @sig: signature
> + *
> + * See whether signature verification is allowed based on the ACL for
> + * key usage.
> + */
> +int security_key_verify_signature(const struct key *key, const struct public_key_signature *sig)
> +{
> +	return call_int_hook(key_verify_signature, key, sig);
> +}
>  #endif	/* CONFIG_KEYS */
>  
>  #ifdef CONFIG_AUDIT
> diff --git a/tools/testing/selftests/lsm/lsm_list_modules_test.c b/tools/testing/selftests/lsm/lsm_list_modules_test.c
> index 1cc8a977c711..cf292f976ac4 100644
> --- a/tools/testing/selftests/lsm/lsm_list_modules_test.c
> +++ b/tools/testing/selftests/lsm/lsm_list_modules_test.c
> @@ -131,6 +131,9 @@ TEST(correct_lsm_list_modules)
>  		case LSM_ID_IPE:
>  			name = "ipe";
>  			break;
> +		case LSM_ID_CLAVIS:
> +			name = "clavis";
> +			break;
>  		default:
>  			name = "INVALID";
>  			break;

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

Hi Mimi,

> On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Motivation:
>> 
>> Each end-user has their own security threat model. What is important to one
>> end-user may not be important to another. There is not a right or wrong threat
>> model.
>> 
>> A common request made when adding new kernel changes that could impact the
>> threat model around system kernel keys is to add additional Kconfig options.
>> As kernel developers, it is challenging to both add and keep track of all the
>> Kconfig options around security features that may limit or restrict
>> system key usage.  It is also difficult for a general purpose distro to take
>> advantage of some of these features, since it may prevent some users from
>> executing their workload.
>> 
>> It is the author's belief that it is better left up to the end-user on how
>> kernel keys should be used within their system.
>> 
>> Throughout the Linux kernel, key usage is tracked when doing signature
>> verification with keys contained within one of the system keyrings;  however,
>> there isn't a way for the end-user to enforce this usage.  This series gives the
>> end-user the ability to configure key usage based on their threat model.
>> Having the ability to enforce key usage also improves security by reducing the
>> attack surface should a system key be compromised. It allows new features to be
>> added without the need for additional Kconfig options for fear of changing the
>> end-user's threat model. It also allows a distro to build a kernel that suits
>> various end-user's needs without resorting to selecting Kconfig options with
>> the least restrictive security options.
> 
> The motivation for this patch set is convincing and addresses limiting the usage
> of keys loaded directly or indirectly onto the system trusted keyrings - 
> .builtin, .machine, and .secondary_trusted_keys keyrings.  Pre-loading the build
> time ephemeral kernel module signing key is a nice improvement from the previous
> versions.  

Apologies for the delayed response and thanks for your feedback on this 
and the other patches you reviewed in the series.

> My main concern is not with Clavis per-se, but that the LSM
> infrastructure allows configuring all the LSMs, but enabling at build time and
> modifying at runtime a subset of them.  Without Clavis enabled, nothing changes
> - any key on the system trusted keyrings remains usable for any purpose.  With
> the current LSM design, the end user security threat model cannot be guaranteed.

I went in the direction of creating a new LSM based on this discussion [1].  
I was hoping to get some feedback from Paul, since I believe I have 
addressed the guidelines for a new LSM.  Currently, the Clavis LSM only 
adds a single LSM hook.  To address your concern, maybe Clavis shouldn't 
be a LSM?  Possibly it could live in the keyring code on its own.

1. https://lkml.org/lkml/2023/10/5/312

Re: [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check

[Eric Snowberg]

> On Dec 23, 2024, at 6:21 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> Hi Eric,
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this
>> pattern does not need to be repeated with new code.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> 
> Ok. The reason why testing the Kconfig is unnecessary should be included in the
> patch description.  For example,
> 
> Commit 219a3e8676f3 ("integrity, KEYS: add a reference to platform keyring")
> unnecessarily added the Kconfig test.  As platform_trusted_keys is already
> initialized, simply use it.

Thanks, I'll add that in the next round.

> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

Re: [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Eric Snowberg]

> On Dec 23, 2024, at 5:01 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Introduce a new system keyring called clavis.  This keyring shall contain
>> a single asymmetric key. This key may be a linked to a key already
>> contained in one of the system keyrings (builtin, secondary, or platform).
> 
> Although "This key may be a linked to ..." is might be correct.  Being
> introduced in this patch is only the ability of loading a key by specifying it
> on the boot command line.  In this case, the key must be on one of the system
> keyrings.

I'll reword this

>> One way to add this key into this keyring is during boot by passing in the
>> asymmetric key id within the new "clavis=" boot param.  If a matching key
>> is found in one of the system keyrings, a link shall be created. This
>> keyring will be used in the future by the new Clavis LSM.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> .../admin-guide/kernel-parameters.txt         |   6 +
>> include/linux/integrity.h                     |   8 ++
>> security/Kconfig                              |   1 +
>> security/Makefile                             |   1 +
>> security/clavis/Kconfig                       |  11 ++
>> security/clavis/Makefile                      |   3 +
>> security/clavis/clavis.h                      |  13 ++
>> security/clavis/clavis_keyring.c              | 115 ++++++++++++++++++
>> security/integrity/iint.c                     |   2 +
>> 9 files changed, 160 insertions(+)
>> create mode 100644 security/clavis/Kconfig
>> create mode 100644 security/clavis/Makefile
>> create mode 100644 security/clavis/clavis.h
>> create mode 100644 security/clavis/clavis_keyring.c
>> 
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 1518343bbe22..d71397e7d254 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -645,6 +645,12 @@
>> cio_ignore= [S390]
>> See Documentation/arch/s390/common_io.rst for details.
>> 
>> + clavis= [SECURITY,EARLY]
>> + Identifies a specific key contained in one of the system
>> + keyrings (builtin, secondary, or platform) to be used as
>> + the Clavis root of trust.
>> + Format: { <keyid> }
> 
> Include .machine keyring here.

and I'll add this too.

>> +
>> clearcpuid=X[,X...] [X86]
>> Disable CPUID feature X for the kernel. See
>> arch/x86/include/asm/cpufeatures.h for the valid bit
>> diff --git a/include/linux/integrity.h b/include/linux/integrity.h
>> index f5842372359b..837c52e1d83b 100644
>> --- a/include/linux/integrity.h
>> +++ b/include/linux/integrity.h
>> @@ -23,6 +23,14 @@ enum integrity_status {
>> #ifdef CONFIG_INTEGRITY
>> extern void __init integrity_load_keys(void);
>> 
>> +#ifdef CONFIG_SECURITY_CLAVIS
>> +void __init late_init_clavis_setup(void);
>> +#else
>> +static inline void late_init_clavis_setup(void)
>> +{
>> +}
>> +#endif
>> +
>> #else
>> static inline void integrity_load_keys(void)
>> {
>> diff --git a/security/Kconfig b/security/Kconfig
>> index 28e685f53bd1..714ec08dda96 100644
>> --- a/security/Kconfig
>> +++ b/security/Kconfig
>> @@ -225,6 +225,7 @@ source "security/safesetid/Kconfig"
>> source "security/lockdown/Kconfig"
>> source "security/landlock/Kconfig"
>> source "security/ipe/Kconfig"
>> +source "security/clavis/Kconfig"
>> 
>> source "security/integrity/Kconfig"
>> 
>> diff --git a/security/Makefile b/security/Makefile
>> index cc0982214b84..69576551007a 100644
>> --- a/security/Makefile
>> +++ b/security/Makefile
>> @@ -26,6 +26,7 @@ obj-$(CONFIG_CGROUPS) += device_cgroup.o
>> obj-$(CONFIG_BPF_LSM) += bpf/
>> obj-$(CONFIG_SECURITY_LANDLOCK) += landlock/
>> obj-$(CONFIG_SECURITY_IPE) += ipe/
>> +obj-$(CONFIG_SECURITY_CLAVIS) += clavis/
>> 
>> # Object integrity file lists
>> obj-$(CONFIG_INTEGRITY) += integrity/
>> diff --git a/security/clavis/Kconfig b/security/clavis/Kconfig
>> new file mode 100644
>> index 000000000000..04f7565f2e2b
>> --- /dev/null
>> +++ b/security/clavis/Kconfig
>> @@ -0,0 +1,11 @@
>> +config SECURITY_CLAVIS
>> + bool "Clavis keyring"
> 
> Isn't SECURITY_CLAVIS the new LSM?  Why is the bool defined as just "Clavis
> keyring"?
> 
>> + depends on SECURITY
>> + select SYSTEM_DATA_VERIFICATION
>> + select CRYPTO_SHA256
>> + help
>> +   Enable the clavis keyring. This keyring shall contain a single asymmetric key.
>> +   This key shall be linked to a key already contained in one of the system
>> +   keyrings (builtin, secondary, or platform). One way to add this key
>> +   is during boot by passing in the asymmetric key id within the "clavis=" boot
>> +   param.  This keyring is required by the Clavis LSM.
> 
> If SECURITY_CLAVIS is a new LSM, the 'help' shouldn't be limited to just the
> clavis keyring, but written at a higher level describing the new LSM.  For
> example,
> 
> This option enables the Clavis LSM, which provides the ability to configure and
> enforce the usage of keys contained on the system keyrings -
> .builtin_trusted_keys, .secondary_trusted_keys, .machine, and .platform
> keyrings.  The clavis LSM defines a keyring named "clavis", which contains a
> single asymmetric key and the key usage rules.
> 
> The single asymmetric key may be specified on the boot command line ...
> 
> [The patch that introduces the key usage rules would add additional info here.]
> 
> [The patch that adds the Documentatoin would add a reference here.]

I went the route of creating the keyring in this patch and then introducing the 
LSM which uses it in a later patch.  My reasoning was it can be tested 
independently.  Also, I thought it would make it easier to review, since 
everything isn't contained within a single patch.  I could look at combining 
them together if you think that would be better.

> 
>> diff --git a/security/clavis/Makefile b/security/clavis/Makefile
>> new file mode 100644
>> index 000000000000..16c451f45f37
>> --- /dev/null
>> +++ b/security/clavis/Makefile
>> @@ -0,0 +1,3 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +
>> +obj-$(CONFIG_SECURITY_CLAVIS) += clavis_keyring.o
>> diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h
>> new file mode 100644
>> index 000000000000..5e397b55a60a
>> --- /dev/null
>> +++ b/security/clavis/clavis.h
>> @@ -0,0 +1,13 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _SECURITY_CLAVIS_H_
>> +#define _SECURITY_CLAVIS_H_
>> +#include <keys/asymmetric-type.h>
>> +
>> +/* Max length for the asymmetric key id contained on the boot param */
>> +#define CLAVIS_BIN_KID_MAX   32
>> +
>> +struct asymmetric_setup_kid {
>> + struct asymmetric_key_id id;
>> + unsigned char data[CLAVIS_BIN_KID_MAX];
>> +};
>> +#endif /* _SECURITY_CLAVIS_H_ */
>> diff --git a/security/clavis/clavis_keyring.c b/security/clavis/clavis_keyring.c
>> new file mode 100644
>> index 000000000000..400ed455a3a2
>> --- /dev/null
>> +++ b/security/clavis/clavis_keyring.c
>> @@ -0,0 +1,115 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +#include <linux/security.h>
>> +#include <linux/integrity.h>
>> +#include <keys/asymmetric-type.h>
>> +#include <keys/system_keyring.h>
>> +#include "clavis.h"
>> +
>> +static struct key *clavis_keyring;
>> +static struct asymmetric_key_id *clavis_boot_akid;
>> +static struct asymmetric_setup_kid clavis_setup_akid;
>> +static bool clavis_enforced;
>> +
>> +static bool clavis_acl_enforced(void)
>> +{
>> + return clavis_enforced;
>> +}
> 
> Add blank line between functions.

I'll add the blank line in the next round.  Thanks.

Re: [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE)

[Eric Snowberg]

> On Dec 23, 2024, at 5:17 PM, Mimi Zohar <zohar@linux.ibm.com> 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:
> 
> Add "fallthrough;"
> 
> https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
> 

I'll add the fallthrough in the next round, thanks.

Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[Eric Snowberg]

> On Dec 24, 2024, at 10:43 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
>> Introduce a new LSM called clavis.  The motivation behind this LSM is to
>> provide access control for system keys.  The access control list is
>> contained within a keyring call .clavis.  During boot if the clavis= boot
>> arg is supplied with a key id contained within any of the current system
>> keyrings (builtin, secondary, machine, or platform) it shall be used as
>> the root of trust for validating anything that is added to the ACL list.
>> 
>> The first restriction introduced with this LSM is the ability to enforce
>> key usage.  The kernel already has a notion of tracking key usage.  This
>> LSM adds the ability to enforce this usage based on the system owners
>> configuration.
>> 
>> Each system key may have one or more uses defined within the ACL list.
>> Until an entry is added to the .clavis keyring, no other system key may
>> be used for any other purpose.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++++++++++++++
>> MAINTAINERS                                   |   7 +
>> crypto/asymmetric_keys/signature.c            |   4 +
>> include/linux/lsm_count.h                     |   8 +-
>> include/linux/lsm_hook_defs.h                 |   2 +
>> include/linux/security.h                      |   7 +
>> include/uapi/linux/lsm.h                      |   1 +
>> security/Kconfig                              |  10 +-
>> security/clavis/Makefile                      |   1 +
>> security/clavis/clavis.c                      |  26 +++
>> security/clavis/clavis.h                      |   4 +
>> security/clavis/clavis_keyring.c              |  78 ++++++-
>> security/security.c                           |  13 ++
>> .../selftests/lsm/lsm_list_modules_test.c     |   3 +
>> 14 files changed, 346 insertions(+), 9 deletions(-)
>> create mode 100644 Documentation/admin-guide/LSM/clavis.rst
>> create mode 100644 security/clavis/clavis.c
>> 
>> diff --git a/Documentation/admin-guide/LSM/clavis.rst b/Documentation/admin-guide/LSM/clavis.rst
>> new file mode 100644
>> index 000000000000..0e924f638a86
>> --- /dev/null
>> +++ b/Documentation/admin-guide/LSM/clavis.rst
>> @@ -0,0 +1,191 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +======
>> +Clavis
>> +======
>> +
>> +Clavis is a Linux Security Module that provides mandatory access control to
>> +system kernel keys (i.e. builtin, secondary, machine and platform). These
>> +restrictions will prohibit keys from being used for validation. Upon boot, the
>> +Clavis LSM is provided a key id as a boot parameter.  This single key is then
>> +used as the root of trust for any access control modifications made going
>> +forward. Access control updates must be signed and validated by this key.
>> +
>> +Clavis has its own keyring.  All ACL updates are applied through this keyring.
>> +The update must be signed by the single root of trust key.
>> +
>> +When enabled, all system keys are prohibited from being used until an ACL is
>> +added for them.
> 
> Until the single key has been loaded, Clavis is not enabled.  Any key on the
> system trusted keyrings remains usable for any purpose.
> 
> -> When enabled, meaning the single key has been loaded onto the Clavis keyring,
> all system keys are prohibited ...
> 
> Until clavis is enabled, in my opinion the defaults should be restrictive (e.g.
> CONFIG_INTEGRITY_CA_MACHINE_KEYRING,
> CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN). Once Clavis is enabled,
> based on a new helper function is_clavis_enforced() we could consider relaxing
> some of the existing keyring requirements (e.g. kernel modules).

If I made this change, would it be acceptable to update the Kconfig 
description for CONFIG_INTEGRITY_CA_MACHINE_KEYRING and CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN 
that the restriction only applies when Clavis is not enabled?  You don't 
think there would be push back that those restrictions are not always 
being enforced?

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Jan 3, 2025 at 6:14 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:

...

> > My main concern is not with Clavis per-se, but that the LSM
> > infrastructure allows configuring all the LSMs, but enabling at build time and
> > modifying at runtime a subset of them.  Without Clavis enabled, nothing changes
> > - any key on the system trusted keyrings remains usable for any purpose.  With
> > the current LSM design, the end user security threat model cannot be guaranteed.
>
> I went in the direction of creating a new LSM based on this discussion [1].
> I was hoping to get some feedback from Paul, since I believe I have
> addressed the guidelines for a new LSM.  Currently, the Clavis LSM only
> adds a single LSM hook.  To address your concern, maybe Clavis shouldn't
> be a LSM?  Possibly it could live in the keyring code on its own.

My turn to apologize for a very late reply, you've been very patient
and I appreciate that.

With respect to Mimi's concerns about disabling Clavis, or any LSM for
that matter, at runtime, doing so requires the ability to modify the
kernel's command line.  I would argue that if a user can manipulate
the kernel command line there are more serious issues that need to be
dealt with first.  Any user who is seriously concerned about the state
of their system should have some mechanism in place to ensure that the
kernel command line is not subject to tampering; thankfully there are
efforts underway to help bring tamper resistant command lines to a
larger audience (the UKI work).

I can't remember if anyone has ever brought this up on-list, and if so
what objections there may have been, but I've always wondered if the
real problem is simply that we use a handful of keyrings for far too
many things inside the kernel.  What terrible things would need to be
overcome if we created additional keyrings based on usage, e.g.
".modulesigning", and used these task specific keyrings instead of the
existing source/trust oriented keyrings?  I imagine we would likely
need some mechanism to link a key from the existing source/trust
keyrings, e.g. ".machine", to a task specific keyring, e.g.
".modulesigning", but I can't imagine that would be too difficult.

Regardless, back to Clavis ... reading quickly through the cover
letter again, I do somewhat wonder if this isn't better integrated
into the keyring proper; have you talked to both David and Jarkko
about this?  Were they supportive of the idea, but simply felt it was
better as an LSM?  I see Jarkko has reviewed and commented on a number
of the patches, so I'll take that as an implicit acceptance of the
concept, but have you heard anything from David?

-- 
paul-moore.com

Re: [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis

[Mimi Zohar]

Hi Eric,

On Fri, 2025-01-03 at 23:27 +0000, Eric Snowberg wrote:
> > > +config SECURITY_CLAVIS
> > > + bool "Clavis keyring"
> > 
> > Isn't SECURITY_CLAVIS the new LSM?  Why is the bool defined as just "Clavis
> > keyring"?
> > 
> > > + depends on SECURITY
> > > + select SYSTEM_DATA_VERIFICATION
> > > + select CRYPTO_SHA256
> > > + help
> > > +   Enable the clavis keyring. This keyring shall contain a single asymmetric key.
> > > +   This key shall be linked to a key already contained in one of the system
> > > +   keyrings (builtin, secondary, or platform). One way to add this key
> > > +   is during boot by passing in the asymmetric key id within the "clavis=" boot
> > > +   param.  This keyring is required by the Clavis LSM.
> > 
> > If SECURITY_CLAVIS is a new LSM, the 'help' shouldn't be limited to just the
> > clavis keyring, but written at a higher level describing the new LSM.  For
> > example,
> > 
> > This option enables the Clavis LSM, which provides the ability to configure and
> > enforce the usage of keys contained on the system keyrings -
> > .builtin_trusted_keys, .secondary_trusted_keys, .machine, and .platform
> > keyrings.  The clavis LSM defines a keyring named "clavis", which contains a
> > single asymmetric key and the key usage rules.
> > 
> > The single asymmetric key may be specified on the boot command line ...
> > 
> > [The patch that introduces the key usage rules would add additional info here.]
> > 
> > [The patch that adds the Documentatoin would add a reference here.]
> 
> I went the route of creating the keyring in this patch and then introducing the 
> LSM which uses it in a later patch.  My reasoning was it can be tested 
> independently.  Also, I thought it would make it easier to review, since 
> everything isn't contained within a single patch.  I could look at combining 
> them together if you think that would be better.

SECURITY_CLAVIS is not just about the CLAVIS keyring, right?  The Kconfig can be
defined and used here, but eventually the SECURITY_CLAVIS "help" needs to be
updated to describe the new LSM.

thanks,

Mimi

Re: [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis

[Mimi Zohar]

On Fri, 2025-01-03 at 23:32 +0000, Eric Snowberg wrote:
> 
> > On Dec 24, 2024, at 10:43 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote:
> > > Introduce a new LSM called clavis.  The motivation behind this LSM is to
> > > provide access control for system keys.  The access control list is
> > > contained within a keyring call .clavis.  During boot if the clavis= boot
> > > arg is supplied with a key id contained within any of the current system
> > > keyrings (builtin, secondary, machine, or platform) it shall be used as
> > > the root of trust for validating anything that is added to the ACL list.
> > > 
> > > The first restriction introduced with this LSM is the ability to enforce
> > > key usage.  The kernel already has a notion of tracking key usage.  This
> > > LSM adds the ability to enforce this usage based on the system owners
> > > configuration.
> > > 
> > > Each system key may have one or more uses defined within the ACL list.
> > > Until an entry is added to the .clavis keyring, no other system key may
> > > be used for any other purpose.
> > > 
> > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> > > ---
> > > Documentation/admin-guide/LSM/clavis.rst      | 191 ++++++++++++++++++
> > > MAINTAINERS                                   |   7 +
> > > crypto/asymmetric_keys/signature.c            |   4 +
> > > include/linux/lsm_count.h                     |   8 +-
> > > include/linux/lsm_hook_defs.h                 |   2 +
> > > include/linux/security.h                      |   7 +
> > > include/uapi/linux/lsm.h                      |   1 +
> > > security/Kconfig                              |  10 +-
> > > security/clavis/Makefile                      |   1 +
> > > security/clavis/clavis.c                      |  26 +++
> > > security/clavis/clavis.h                      |   4 +
> > > security/clavis/clavis_keyring.c              |  78 ++++++-
> > > security/security.c                           |  13 ++
> > > .../selftests/lsm/lsm_list_modules_test.c     |   3 +
> > > 14 files changed, 346 insertions(+), 9 deletions(-)
> > > create mode 100644 Documentation/admin-guide/LSM/clavis.rst
> > > create mode 100644 security/clavis/clavis.c
> > > 
> > > diff --git a/Documentation/admin-guide/LSM/clavis.rst b/Documentation/admin-guide/LSM/clavis.rst
> > > new file mode 100644
> > > index 000000000000..0e924f638a86
> > > --- /dev/null
> > > +++ b/Documentation/admin-guide/LSM/clavis.rst
> > > @@ -0,0 +1,191 @@
> > > +.. SPDX-License-Identifier: GPL-2.0
> > > +
> > > +======
> > > +Clavis
> > > +======
> > > +
> > > +Clavis is a Linux Security Module that provides mandatory access control to
> > > +system kernel keys (i.e. builtin, secondary, machine and platform). These
> > > +restrictions will prohibit keys from being used for validation. Upon boot, the
> > > +Clavis LSM is provided a key id as a boot parameter.  This single key is then
> > > +used as the root of trust for any access control modifications made going
> > > +forward. Access control updates must be signed and validated by this key.
> > > +
> > > +Clavis has its own keyring.  All ACL updates are applied through this keyring.
> > > +The update must be signed by the single root of trust key.
> > > +
> > > +When enabled, all system keys are prohibited from being used until an ACL is
> > > +added for them.
> > 
> > Until the single key has been loaded, Clavis is not enabled.  Any key on the
> > system trusted keyrings remains usable for any purpose.
> > 
> > -> When enabled, meaning the single key has been loaded onto the Clavis keyring,
> > all system keys are prohibited ...
> > 
> > Until clavis is enabled, in my opinion the defaults should be restrictive (e.g.
> > CONFIG_INTEGRITY_CA_MACHINE_KEYRING,
> > CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN). Once Clavis is enabled,
> > based on a new helper function is_clavis_enforced() we could consider relaxing
> > some of the existing keyring requirements (e.g. kernel modules).

For example, kernel/module/signing.c: mod_verify_sig() would be updated to check
whether Clavis is configured and enabled and then search/use keys on the other
system keyrings.

> 
> If I made this change, would it be acceptable to update the Kconfig 
> description for CONFIG_INTEGRITY_CA_MACHINE_KEYRING and CONFIG_SECONDARY_TRUSTED_KEYRING_SIGNED_BY_BUILTIN 
> that the restriction only applies when Clavis is not enabled?  You don't 
> think there would be push back that those restrictions are not always 
> being enforced?

Instead I would add a Kconfig "Note:" indicating that enabling Clavis relaxes
the requirement that the key exists on the system trusted
.secondary_trusted_keys keyring.

thanks,

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
>
> Regardless, back to Clavis ... reading quickly through the cover
> letter again, I do somewhat wonder if this isn't better integrated
> into the keyring proper; have you talked to both David and Jarkko
> about this?

I realize I should probably expand on my thinking a bit, especially
since my comment a while regarding LSMs dedicated to enforcing access
control on keys is what was given as a reason for making Clavis a LSM.

I still stand by my comment from over a year ago that I see no reason
why we couldn't support a LSM that enforces access controls on
keyrings/keys.  What gives me pause with the Clavis LSM is that so
much of Clavis is resident in the keyrings themselves, e.g. Clavis
policy ACLs and authorization keys, that it really feels like it
should be part of the keys subsystem and not a LSM.  Yes, existing
LSMs do have LSM specific data that resides outside of the LSM and in
an object's subsystem, but that is usually limited to security
identifiers and similar things, not the LSM's security policy.

That's my current thinking, and why I asked about locating Clavis in
the keys subsystem directly (although I still think better keyring
granularity and a shift towards usage based keyrings is the better
option).  If David and Jarkko are opposed to integrating Clavis into
the keys subsystem we can consider this as a LSM, I'm just not sure
it's the best first option.  Does that make sense?

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
>> 
>> Regardless, back to Clavis ... reading quickly through the cover
>> letter again, I do somewhat wonder if this isn't better integrated
>> into the keyring proper; have you talked to both David and Jarkko
>> about this?
> 
> I realize I should probably expand on my thinking a bit, especially
> since my comment a while regarding LSMs dedicated to enforcing access
> control on keys is what was given as a reason for making Clavis a LSM.
> 
> I still stand by my comment from over a year ago that I see no reason
> why we couldn't support a LSM that enforces access controls on
> keyrings/keys.  What gives me pause with the Clavis LSM is that so
> much of Clavis is resident in the keyrings themselves, e.g. Clavis
> policy ACLs and authorization keys, that it really feels like it
> should be part of the keys subsystem and not a LSM.  Yes, existing
> LSMs do have LSM specific data that resides outside of the LSM and in
> an object's subsystem, but that is usually limited to security
> identifiers and similar things, not the LSM's security policy.
> 
> That's my current thinking, and why I asked about locating Clavis in
> the keys subsystem directly (although I still think better keyring
> granularity and a shift towards usage based keyrings is the better
> option).  If David and Jarkko are opposed to integrating Clavis into
> the keys subsystem we can consider this as a LSM, I'm just not sure
> it's the best first option.  Does that make sense?

Thanks for your feedback Paul.  I have no preference if it is a new LSM 
or not.  My interest is finding the path of least resistance to get this type 
of capability added to mainline code.  Hopefully David and Jarkko will 
provide their opinions. 

Re: [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key

[Jarkko Sakkinen]

On Thu, Oct 17, 2024 at 09:55:10AM -0600, Eric Snowberg wrote:
> Add two new fields in public_key_signature to track the intended usage of
> the signature.  Also add a flag for the revocation pass.  During signature
> validation, two verifications can take place for the same signature.  One
> to see if it verifies against something on the .blacklist keyring and
> the other to see if it verifies against the supplied keyring. The flag
> is used to determine which stage the verification is in.
> 
> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

Mimi, was this the patch set you asked to look at while ago?</offtopic>

This patch adds PKS_REVOCATION_PASS and REVOCATION_SET. It would be
nice to put in simple terms how they are used in down to eart terms.

> ---
>  certs/blacklist.c                     |  3 +++
>  crypto/asymmetric_keys/pkcs7_trust.c  | 20 ++++++++++++++++++++
>  crypto/asymmetric_keys/pkcs7_verify.c |  4 ++++
>  include/crypto/pkcs7.h                |  3 +++
>  include/crypto/public_key.h           |  4 ++++
>  5 files changed, 34 insertions(+)
> 
> diff --git a/certs/blacklist.c b/certs/blacklist.c
> index 675dd7a8f07a..dd34e56a6362 100644
> --- a/certs/blacklist.c
> +++ b/certs/blacklist.c
> @@ -17,6 +17,7 @@
>  #include <linux/uidgid.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
> +#include <crypto/public_key.h>
>  #include "blacklist.h"
>  
>  /*
> @@ -289,7 +290,9 @@ int is_key_on_revocation_list(struct pkcs7_message *pkcs7)
>  {
>  	int ret;
>  
> +	pkcs7_set_usage_flag(pkcs7, PKS_REVOCATION_PASS);
>  	ret = pkcs7_validate_trust(pkcs7, blacklist_keyring);
> +	pkcs7_clear_usage_flag(pkcs7, PKS_REVOCATION_PASS);
>  
>  	if (ret == 0)
>  		return -EKEYREJECTED;
> diff --git a/crypto/asymmetric_keys/pkcs7_trust.c b/crypto/asymmetric_keys/pkcs7_trust.c
> index 9a87c34ed173..64d70eb68864 100644
> --- a/crypto/asymmetric_keys/pkcs7_trust.c
> +++ b/crypto/asymmetric_keys/pkcs7_trust.c
> @@ -131,6 +131,26 @@ static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
>  	return 0;
>  }
>  
> +void pkcs7_clear_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage)
> +{
> +	struct pkcs7_signed_info *sinfo;
> +
> +	for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
> +		if (sinfo->sig)
> +			clear_bit(usage, &sinfo->sig->usage_flags);
> +	}
> +}
> +
> +void pkcs7_set_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage)
> +{
> +	struct pkcs7_signed_info *sinfo;
> +
> +	for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
> +		if (sinfo->sig)
> +			set_bit(usage, &sinfo->sig->usage_flags);
> +	}
> +}
> +
>  /**
>   * pkcs7_validate_trust - Validate PKCS#7 trust chain
>   * @pkcs7: The PKCS#7 certificate to validate
> diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
> index 1dc80e68ce96..44b8bd0ad4d8 100644
> --- a/crypto/asymmetric_keys/pkcs7_verify.c
> +++ b/crypto/asymmetric_keys/pkcs7_verify.c
> @@ -455,6 +455,10 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
>  			return ret;
>  		}
>  		actual_ret = 0;
> +		if (sinfo->sig) {
> +			sinfo->sig->usage = usage;
> +			set_bit(PKS_USAGE_SET, &sinfo->sig->usage_flags);
> +		}
>  	}
>  
>  	kleave(" = %d", actual_ret);
> diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
> index 38ec7f5f9041..6c3c9061b118 100644
> --- a/include/crypto/pkcs7.h
> +++ b/include/crypto/pkcs7.h
> @@ -32,6 +32,9 @@ extern int pkcs7_get_content_data(const struct pkcs7_message *pkcs7,
>  extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
>  				struct key *trust_keyring);
>  
> +extern void pkcs7_set_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage);
> +extern void pkcs7_clear_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage);
> +
>  /*
>   * pkcs7_verify.c
>   */
> diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
> index b7f308977c84..394022b5d856 100644
> --- a/include/crypto/public_key.h
> +++ b/include/crypto/public_key.h
> @@ -49,6 +49,10 @@ struct public_key_signature {
>  	const char *pkey_algo;
>  	const char *hash_algo;
>  	const char *encoding;
> +	u32 usage;		/* Intended usage */

I'd would not size encode this but instead use "unsigned int".

> +	unsigned long usage_flags;

It would be less convoluting if this was just "flags". Now this leaves
to wonder what it is encoded for. E.g. for ioctl API one doees it for
the API to be size agnostic between 32/64-bit kernels.

> +#define PKS_USAGE_SET		0
> +#define PKS_REVOCATION_PASS	1
>  };

I'd add these before the struct and:

/* ... */
#define PKS_USAGE_SET		0

/* ... */
#define PKS_REVOCATION_PASS	1

>  
>  extern void public_key_signature_free(struct public_key_signature *sig);
> -- 
> 2.45.0
> 

BR, Jarkko

Re: [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key

[Eric Snowberg]

> On Feb 6, 2025, at 1:13 PM, Jarkko Sakkinen <jarkko.sakkinen@kernel.org> wrote:
> 
> On Thu, Oct 17, 2024 at 09:55:10AM -0600, Eric Snowberg wrote:
>> Add two new fields in public_key_signature to track the intended usage of
>> the signature.  Also add a flag for the revocation pass.  During signature
>> validation, two verifications can take place for the same signature.  One
>> to see if it verifies against something on the .blacklist keyring and
>> the other to see if it verifies against the supplied keyring. The flag
>> is used to determine which stage the verification is in.
>> 
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> 
> Mimi, was this the patch set you asked to look at while ago?</offtopic>
> 
> This patch adds PKS_REVOCATION_PASS and REVOCATION_SET. It would be
> nice to put in simple terms how they are used in down to eart terms.

Ok, I'll add more details explaining them better in the next round.

>> ---
>> certs/blacklist.c                     |  3 +++
>> crypto/asymmetric_keys/pkcs7_trust.c  | 20 ++++++++++++++++++++
>> crypto/asymmetric_keys/pkcs7_verify.c |  4 ++++
>> include/crypto/pkcs7.h                |  3 +++
>> include/crypto/public_key.h           |  4 ++++
>> 5 files changed, 34 insertions(+)
>> 
>> diff --git a/certs/blacklist.c b/certs/blacklist.c
>> index 675dd7a8f07a..dd34e56a6362 100644
>> --- a/certs/blacklist.c
>> +++ b/certs/blacklist.c
>> @@ -17,6 +17,7 @@
>> #include <linux/uidgid.h>
>> #include <keys/asymmetric-type.h>
>> #include <keys/system_keyring.h>
>> +#include <crypto/public_key.h>
>> #include "blacklist.h"
>> 
>> /*
>> @@ -289,7 +290,9 @@ int is_key_on_revocation_list(struct pkcs7_message *pkcs7)
>> {
>> int ret;
>> 
>> + pkcs7_set_usage_flag(pkcs7, PKS_REVOCATION_PASS);
>> ret = pkcs7_validate_trust(pkcs7, blacklist_keyring);
>> + pkcs7_clear_usage_flag(pkcs7, PKS_REVOCATION_PASS);
>> 
>> if (ret == 0)
>> return -EKEYREJECTED;
>> diff --git a/crypto/asymmetric_keys/pkcs7_trust.c b/crypto/asymmetric_keys/pkcs7_trust.c
>> index 9a87c34ed173..64d70eb68864 100644
>> --- a/crypto/asymmetric_keys/pkcs7_trust.c
>> +++ b/crypto/asymmetric_keys/pkcs7_trust.c
>> @@ -131,6 +131,26 @@ static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
>> return 0;
>> }
>> 
>> +void pkcs7_clear_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage)
>> +{
>> + struct pkcs7_signed_info *sinfo;
>> +
>> + for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
>> + if (sinfo->sig)
>> + clear_bit(usage, &sinfo->sig->usage_flags);
>> + }
>> +}
>> +
>> +void pkcs7_set_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage)
>> +{
>> + struct pkcs7_signed_info *sinfo;
>> +
>> + for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
>> + if (sinfo->sig)
>> + set_bit(usage, &sinfo->sig->usage_flags);
>> + }
>> +}
>> +
>> /**
>>  * pkcs7_validate_trust - Validate PKCS#7 trust chain
>>  * @pkcs7: The PKCS#7 certificate to validate
>> diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
>> index 1dc80e68ce96..44b8bd0ad4d8 100644
>> --- a/crypto/asymmetric_keys/pkcs7_verify.c
>> +++ b/crypto/asymmetric_keys/pkcs7_verify.c
>> @@ -455,6 +455,10 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
>> return ret;
>> }
>> actual_ret = 0;
>> + if (sinfo->sig) {
>> + sinfo->sig->usage = usage;
>> + set_bit(PKS_USAGE_SET, &sinfo->sig->usage_flags);
>> + }
>> }
>> 
>> kleave(" = %d", actual_ret);
>> diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
>> index 38ec7f5f9041..6c3c9061b118 100644
>> --- a/include/crypto/pkcs7.h
>> +++ b/include/crypto/pkcs7.h
>> @@ -32,6 +32,9 @@ extern int pkcs7_get_content_data(const struct pkcs7_message *pkcs7,
>> extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
>> struct key *trust_keyring);
>> 
>> +extern void pkcs7_set_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage);
>> +extern void pkcs7_clear_usage_flag(struct pkcs7_message *pkcs7, unsigned long usage);
>> +
>> /*
>>  * pkcs7_verify.c
>>  */
>> diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
>> index b7f308977c84..394022b5d856 100644
>> --- a/include/crypto/public_key.h
>> +++ b/include/crypto/public_key.h
>> @@ -49,6 +49,10 @@ struct public_key_signature {
>> const char *pkey_algo;
>> const char *hash_algo;
>> const char *encoding;
>> + u32 usage; /* Intended usage */
> 
> I'd would not size encode this but instead use "unsigned int".

I'll change that

> 
>> + unsigned long usage_flags;
> 
> It would be less convoluting if this was just "flags". Now this leaves
> to wonder what it is encoded for. E.g. for ioctl API one doees it for
> the API to be size agnostic between 32/64-bit kernels.

and change usage_flags to just "flags"

> 
>> +#define PKS_USAGE_SET 0
>> +#define PKS_REVOCATION_PASS 1
>> };
> 
> I'd add these before the struct and:
> 
> /* ... */
> #define PKS_USAGE_SET 0
> 
> /* ... */
> #define PKS_REVOCATION_PASS 1

I was following the same pattern done elsewhere in the crypto code, 
but I can move them before the structure.

>> 
>> extern void public_key_signature_free(struct public_key_signature *sig);
>> -- 
>> 2.45.0
>> 
> 
> BR, Jarkko

Thanks for your review.

Re: [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key

[Mimi Zohar]

On Thu, 2025-02-06 at 22:13 +0200, Jarkko Sakkinen wrote:
> On Thu, Oct 17, 2024 at 09:55:10AM -0600, Eric Snowberg wrote:
> > Add two new fields in public_key_signature to track the intended usage of
> > the signature.  Also add a flag for the revocation pass.  During signature
> > validation, two verifications can take place for the same signature.  One
> > to see if it verifies against something on the .blacklist keyring and
> > the other to see if it verifies against the supplied keyring. The flag
> > is used to determine which stage the verification is in.
> > 
> > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> 
> Mimi, was this the patch set you asked to look at while ago?</offtopic>

Yes, in particular please take a look at Paul's comment on 00/13.

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote:
> 
> > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > 
> > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > 
> > > Regardless, back to Clavis ... reading quickly through the cover
> > > letter again, I do somewhat wonder if this isn't better integrated
> > > into the keyring proper; have you talked to both David and Jarkko
> > > about this?
> > 
> > I realize I should probably expand on my thinking a bit, especially
> > since my comment a while regarding LSMs dedicated to enforcing access
> > control on keys is what was given as a reason for making Clavis a LSM.
> > 
> > I still stand by my comment from over a year ago that I see no reason
> > why we couldn't support a LSM that enforces access controls on
> > keyrings/keys.  What gives me pause with the Clavis LSM is that so
> > much of Clavis is resident in the keyrings themselves, e.g. Clavis
> > policy ACLs and authorization keys, that it really feels like it
> > should be part of the keys subsystem and not a LSM.  Yes, existing
> > LSMs do have LSM specific data that resides outside of the LSM and in
> > an object's subsystem, but that is usually limited to security
> > identifiers and similar things, not the LSM's security policy.

Hi Jarkko, David,

Both Paul's and my main concerns with this patch set is storing policy in the
keyring.  We would appreciate your chiming in here about storing key policy in
the keyring itself.

thanks,

Mimi

> > 
> > That's my current thinking, and why I asked about locating Clavis in
> > the keys subsystem directly (although I still think better keyring
> > granularity and a shift towards usage based keyrings is the better
> > option).  If David and Jarkko are opposed to integrating Clavis into
> > the keys subsystem we can consider this as a LSM, I'm just not sure
> > it's the best first option.  Does that make sense?
> 
> Thanks for your feedback Paul.  I have no preference if it is a new LSM 
> or not.  My interest is finding the path of least resistance to get this type 
> of capability added to mainline code.  Hopefully David and Jarkko will 
> provide their opinions.

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote:
> > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > Regardless, back to Clavis ... reading quickly through the cover
> > > > letter again, I do somewhat wonder if this isn't better integrated
> > > > into the keyring proper; have you talked to both David and Jarkko
> > > > about this?
> > >
> > > I realize I should probably expand on my thinking a bit, especially
> > > since my comment a while regarding LSMs dedicated to enforcing access
> > > control on keys is what was given as a reason for making Clavis a LSM.
> > >
> > > I still stand by my comment from over a year ago that I see no reason
> > > why we couldn't support a LSM that enforces access controls on
> > > keyrings/keys.  What gives me pause with the Clavis LSM is that so
> > > much of Clavis is resident in the keyrings themselves, e.g. Clavis
> > > policy ACLs and authorization keys, that it really feels like it
> > > should be part of the keys subsystem and not a LSM.  Yes, existing
> > > LSMs do have LSM specific data that resides outside of the LSM and in
> > > an object's subsystem, but that is usually limited to security
> > > identifiers and similar things, not the LSM's security policy.
>
> Hi Jarkko, David,
>
> Both Paul's and my main concerns with this patch set is storing policy in the
> keyring.  We would appreciate your chiming in here about storing key policy in
> the keyring itself.

I'd still also like to see some discussion about moving towards the
addition of keyrings oriented towards usage instead of limiting
ourselves to keyrings that are oriented on the source of the keys.
Perhaps I'm missing some important detail which makes this
impractical, but it seems like an obvious improvement to me and would
go a long way towards solving some of the problems that we typically
see with kernel keys.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote:
> > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > > 
> > > > > Regardless, back to Clavis ... reading quickly through the cover
> > > > > letter again, I do somewhat wonder if this isn't better integrated
> > > > > into the keyring proper; have you talked to both David and Jarkko
> > > > > about this?
> > > > 
> > > > I realize I should probably expand on my thinking a bit, especially
> > > > since my comment a while regarding LSMs dedicated to enforcing access
> > > > control on keys is what was given as a reason for making Clavis a LSM.
> > > > 
> > > > I still stand by my comment from over a year ago that I see no reason
> > > > why we couldn't support a LSM that enforces access controls on
> > > > keyrings/keys.  What gives me pause with the Clavis LSM is that so
> > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis
> > > > policy ACLs and authorization keys, that it really feels like it
> > > > should be part of the keys subsystem and not a LSM.  Yes, existing
> > > > LSMs do have LSM specific data that resides outside of the LSM and in
> > > > an object's subsystem, but that is usually limited to security
> > > > identifiers and similar things, not the LSM's security policy.
> > 
> > Hi Jarkko, David,
> > 
> > Both Paul's and my main concerns with this patch set is storing policy in the
> > keyring.  We would appreciate your chiming in here about storing key policy in
> > the keyring itself.
> 
> I'd still also like to see some discussion about moving towards the
> addition of keyrings oriented towards usage instead of limiting
> ourselves to keyrings that are oriented on the source of the keys.
> Perhaps I'm missing some important detail which makes this
> impractical, but it seems like an obvious improvement to me and would
> go a long way towards solving some of the problems that we typically
> see with kernel keys.

The proliferation of keyrings won't solve the key usage problem for IMA-
appraisal.  IMA-appraisal can be used to verify the kexec image, kernel modules,
firwmare, etc, but it also verifies file signatures contained in userspace
packages.  To support the latter case, keyrings would need to be application
specific.  (This version of Clavis doesn't solve the latter key usage for IMA-
appraisal either.)

The keys baked into the kernel are trusted because the kernel itself was signed
and verified (secure boot).  Anyone building a kernel can build a key into the
kernel image, which establishes a "root of trust".  That key can then be used to
verify and load other keys onto the IMA keyring.

The problem is how to safely establish a root of trust without baking the key
into the kernel image and then limiting that trust to specific usages or
applications.

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> >
> > I'd still also like to see some discussion about moving towards the
> > addition of keyrings oriented towards usage instead of limiting
> > ourselves to keyrings that are oriented on the source of the keys.
> > Perhaps I'm missing some important detail which makes this
> > impractical, but it seems like an obvious improvement to me and would
> > go a long way towards solving some of the problems that we typically
> > see with kernel keys.
>
> The proliferation of keyrings won't solve the key usage problem for IMA-
> appraisal.  IMA-appraisal can be used to verify the kexec image, kernel modules,
> firwmare, etc, but it also verifies file signatures contained in userspace
> packages.

To be clear I don't think the usage oriented keyring idea will solve
every keyring problem, but it seems like it solves a fair number of
things that I've heard lately.

>  To support the latter case, keyrings would need to be application
> specific.  (This version of Clavis doesn't solve the latter key usage for IMA-
> appraisal either.)

Application specific keyrings are more-or-less what I've been trying
to describe.

> The keys baked into the kernel are trusted because the kernel itself was signed
> and verified (secure boot).  Anyone building a kernel can build a key into the
> kernel image, which establishes a "root of trust".  That key can then be used to
> verify and load other keys onto the IMA keyring.

Sure, I'm not saying that trust isn't important, and that there are
varying levels of trust.  My argument is that having additional,
usage/application oriented keyrings which contain links back to keys
imported and stored in the traditional trust oriented keyrings could
neatly solve a number of keyring access control issues.

> The problem is how to safely establish a root of trust without baking the key
> into the kernel image and then limiting that trust to specific usages or
> applications.

My takeaway from Clavis was that it was more about establishing a set
of access controls around keys already present in the keyrings and my
comments about usage/spplication oriented keyrings have been in that
context.  While the access control policy, regardless of how it is
implemented, should no doubt incorporate the trust placed in the
individual keys, how that trust is established is a separate issue
from access control as far as I'm concerned.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > 
> > > I'd still also like to see some discussion about moving towards the
> > > addition of keyrings oriented towards usage instead of limiting
> > > ourselves to keyrings that are oriented on the source of the keys.
> > > Perhaps I'm missing some important detail which makes this
> > > impractical, but it seems like an obvious improvement to me and would
> > > go a long way towards solving some of the problems that we typically
> > > see with kernel keys.
> > 
> > The proliferation of keyrings won't solve the key usage problem for IMA-
> > appraisal.  IMA-appraisal can be used to verify the kexec image, kernel modules,
> > firwmare, etc, but it also verifies file signatures contained in userspace
> > packages.
> 
> To be clear I don't think the usage oriented keyring idea will solve
> every keyring problem, but it seems like it solves a fair number of
> things that I've heard lately.
> 
> >  To support the latter case, keyrings would need to be application
> > specific.  (This version of Clavis doesn't solve the latter key usage for IMA-
> > appraisal either.)
> 
> Application specific keyrings are more-or-less what I've been trying
> to describe.

Ok, let's go through different scenarios to see if it would scale.

Scenario 1: Mostly distro signed userspace applications, minimum number of
developer, customer, 3rd party applications.

Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
same party.

Scenario 3: extreme case - every application signed by different party.

With the minimum case, there would probably be a default key or sets of
permissible keys.  In the extreme case, the number of keyrings would be
equivalent to the number of application/software packages.

> 
> > The keys baked into the kernel are trusted because the kernel itself was signed
> > and verified (secure boot).  Anyone building a kernel can build a key into the
> > kernel image, which establishes a "root of trust".  That key can then be used to
> > verify and load other keys onto the IMA keyring.
> 
> Sure, I'm not saying that trust isn't important, and that there are
> varying levels of trust.  My argument is that having additional,
> usage/application oriented keyrings which contain links back to keys
> imported and stored in the traditional trust oriented keyrings could
> neatly solve a number of keyring access control issues.
> 
> > The problem is how to safely establish a root of trust without baking the key
> > into the kernel image and then limiting that trust to specific usages or
> > applications.
> 
> My takeaway from Clavis was that it was more about establishing a set
> of access controls around keys already present in the keyrings and my
> comments about usage/spplication oriented keyrings have been in that
> context.  While the access control policy, regardless of how it is
> implemented, should no doubt incorporate the trust placed in the
> individual keys, how that trust is established is a separate issue
> from access control as far as I'm concerned.

Clavis defined both a mechanism for establishing trust and access control rules.

Clavis defined a single Clavis key to establish trust.  The Clavis policy rules
were signed by the Clavis key.  The Clavis policy rules defined the access
control.

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>>> 
>>> I'd still also like to see some discussion about moving towards the
>>> addition of keyrings oriented towards usage instead of limiting
>>> ourselves to keyrings that are oriented on the source of the keys.
>>> Perhaps I'm missing some important detail which makes this
>>> impractical, but it seems like an obvious improvement to me and would
>>> go a long way towards solving some of the problems that we typically
>>> see with kernel keys.

The intent is not to limit ourselves to the source of the key.  The main 
point of Clavis is to allow the end-user to determine what kernel keys 
they want to trust and for what purpose, irrespective of the originating 
source (.builtin_trusted, .secondary, .machine, or .platform). If we could 
go back in time, individual keyrings could be created that are oriented 
toward usage.   The idea for introducing Clavis is to bridge what we 
have today with kernel keys and allow them to be usage based.

>> 
>> The proliferation of keyrings won't solve the key usage problem for IMA-
>> appraisal.  IMA-appraisal can be used to verify the kexec image, kernel modules,
>> firwmare, etc, but it also verifies file signatures contained in userspace
>> packages.
> 
> To be clear I don't think the usage oriented keyring idea will solve
> every keyring problem, but it seems like it solves a fair number of
> things that I've heard lately.
> 
>> To support the latter case, keyrings would need to be application
>> specific.  (This version of Clavis doesn't solve the latter key usage for IMA-
>> appraisal either.)
> 
> Application specific keyrings are more-or-less what I've been trying
> to describe.
> 
>> The keys baked into the kernel are trusted because the kernel itself was signed
>> and verified (secure boot).  Anyone building a kernel can build a key into the
>> kernel image, which establishes a "root of trust".  That key can then be used to
>> verify and load other keys onto the IMA keyring.
> 
> Sure, I'm not saying that trust isn't important, and that there are
> varying levels of trust.  My argument is that having additional,
> usage/application oriented keyrings which contain links back to keys
> imported and stored in the traditional trust oriented keyrings could
> neatly solve a number of keyring access control issues.

I'm not sure I completely follow this. If a user space application wants to 
use system kernel keys in this manner, can't this be  done today? (I'm 
not talking about IMA here).  The keyctl has both the "link" and 
"restrict_keyring". 

Or do you mean take things further with Clavis?  Meaning when usage is
setup for a key, it is then populated in a new usage based keyring?

Re: [RFC PATCH v3 00/13] Clavis LSM

[Jarkko Sakkinen]

On Thu, Feb 27, 2025 at 03:41:18PM -0500, Mimi Zohar wrote:
> On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote:
> > 
> > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > 
> > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > 
> > > > Regardless, back to Clavis ... reading quickly through the cover
> > > > letter again, I do somewhat wonder if this isn't better integrated
> > > > into the keyring proper; have you talked to both David and Jarkko
> > > > about this?
> > > 
> > > I realize I should probably expand on my thinking a bit, especially
> > > since my comment a while regarding LSMs dedicated to enforcing access
> > > control on keys is what was given as a reason for making Clavis a LSM.
> > > 
> > > I still stand by my comment from over a year ago that I see no reason
> > > why we couldn't support a LSM that enforces access controls on
> > > keyrings/keys.  What gives me pause with the Clavis LSM is that so
> > > much of Clavis is resident in the keyrings themselves, e.g. Clavis
> > > policy ACLs and authorization keys, that it really feels like it
> > > should be part of the keys subsystem and not a LSM.  Yes, existing
> > > LSMs do have LSM specific data that resides outside of the LSM and in
> > > an object's subsystem, but that is usually limited to security
> > > identifiers and similar things, not the LSM's security policy.
> 
> Hi Jarkko, David,
> 
> Both Paul's and my main concerns with this patch set is storing policy in the
> keyring.  We would appreciate your chiming in here about storing key policy in
> the keyring itself.

Right so the problem here would be that keyring defines policy for keys?

Like in abstract "textbook sense" a policy should not live within in the
closure that it dictactes. And the most classic issue would be probably
circular dependencies.

Theory aside, in practical sense, can you spot an example from the patch
set where we could introduce issue by having Clavis as it is?

> 
> thanks,
> 
> Mimi

BR, Jarkko

Re: [RFC PATCH v3 00/13] Clavis LSM

[Jarkko Sakkinen]

On Thu, Feb 27, 2025 at 05:22:22PM -0500, Paul Moore wrote:
> On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote:
> > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > >
> > > > > Regardless, back to Clavis ... reading quickly through the cover
> > > > > letter again, I do somewhat wonder if this isn't better integrated
> > > > > into the keyring proper; have you talked to both David and Jarkko
> > > > > about this?
> > > >
> > > > I realize I should probably expand on my thinking a bit, especially
> > > > since my comment a while regarding LSMs dedicated to enforcing access
> > > > control on keys is what was given as a reason for making Clavis a LSM.
> > > >
> > > > I still stand by my comment from over a year ago that I see no reason
> > > > why we couldn't support a LSM that enforces access controls on
> > > > keyrings/keys.  What gives me pause with the Clavis LSM is that so
> > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis
> > > > policy ACLs and authorization keys, that it really feels like it
> > > > should be part of the keys subsystem and not a LSM.  Yes, existing
> > > > LSMs do have LSM specific data that resides outside of the LSM and in
> > > > an object's subsystem, but that is usually limited to security
> > > > identifiers and similar things, not the LSM's security policy.
> >
> > Hi Jarkko, David,
> >
> > Both Paul's and my main concerns with this patch set is storing policy in the
> > keyring.  We would appreciate your chiming in here about storing key policy in
> > the keyring itself.
> 
> I'd still also like to see some discussion about moving towards the
> addition of keyrings oriented towards usage instead of limiting
> ourselves to keyrings that are oriented on the source of the keys.
> Perhaps I'm missing some important detail which makes this
> impractical, but it seems like an obvious improvement to me and would
> go a long way towards solving some of the problems that we typically
> see with kernel keys.

I get the theoretical concern but cannot see anything obvious in the
patch set that would nail into practical concerns. 

> 
> -- 
> paul-moore.com

BR, Jarkko

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:

...

> Ok, let's go through different scenarios to see if it would scale.
>
> Scenario 1: Mostly distro signed userspace applications, minimum number of
> developer, customer, 3rd party applications.
>
> Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> same party.
>
> Scenario 3: extreme case - every application signed by different party.
>
> With the minimum case, there would probably be a default key or sets of
> permissible keys.  In the extreme case, the number of keyrings would be
> equivalent to the number of application/software packages.

Perhaps we're not understanding each other, but my understanding of
the above three scenarios is that they are all examples of signed
applications where something (likely something in the kernel like IMA)
verifies the signature on the application.  While there are going to
be differing numbers of keys in each of the three scenarios, I believe
they would all be on/linked-to the same usage oriented keyring as they
all share the same usage: application signatures.

> > My takeaway from Clavis was that it was more about establishing a set
> > of access controls around keys already present in the keyrings and my
> > comments about usage/spplication oriented keyrings have been in that
> > context.  While the access control policy, regardless of how it is
> > implemented, should no doubt incorporate the trust placed in the
> > individual keys, how that trust is established is a separate issue
> > from access control as far as I'm concerned.
>
> Clavis defined both a mechanism for establishing trust and access control rules.
>
> Clavis defined a single Clavis key to establish trust.  The Clavis policy rules
> were signed by the Clavis key.  The Clavis policy rules defined the access
> control.

Unfortunately I think we're getting a little ambiguous with how we are
using the word "trust".  Just as "security" can mean different things
depending on context, so can "trust" as the qualities we are trusting
will vary depending on context.  I'll leave it at that for now as I
believe we are talking about different things in the paragraphs above.

Regardless, I'll also say this regarding Clavis and key/keyring access
controls - as implemented, Clavis doesn't look like a LSM to me for
the reasons already given.  If all of the various keys subsystem
maintainers believe it is the Right Thing To Do inside the keys
subsystem then it isn't my place to have a say in that.  I personally
believe that doing the work to support usage oriented keyrings before,
or while, implementing a Clavis-like mechanism is the better option,
but that is a decision for you and the other key maintainers.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> >>>
> >>> I'd still also like to see some discussion about moving towards the
> >>> addition of keyrings oriented towards usage instead of limiting
> >>> ourselves to keyrings that are oriented on the source of the keys.
> >>> Perhaps I'm missing some important detail which makes this
> >>> impractical, but it seems like an obvious improvement to me and would
> >>> go a long way towards solving some of the problems that we typically
> >>> see with kernel keys.
>
> The intent is not to limit ourselves to the source of the key.  The main
> point of Clavis is to allow the end-user to determine what kernel keys
> they want to trust and for what purpose, irrespective of the originating
> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> go back in time, individual keyrings could be created that are oriented
> toward usage.   The idea for introducing Clavis is to bridge what we
> have today with kernel keys and allow them to be usage based.

While it is unlikely that the current well known keyrings could be
removed, I see no reason why new usage oriented keyrings could not be
introduced.  We've seen far more significant shifts in the kernel over
the years.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> 
> ...
> 
> > Ok, let's go through different scenarios to see if it would scale.
> > 
> > Scenario 1: Mostly distro signed userspace applications, minimum number of
> > developer, customer, 3rd party applications.
> > 
> > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> > same party.
> > 
> > Scenario 3: extreme case - every application signed by different party.
> > 
> > With the minimum case, there would probably be a default key or sets of
> > permissible keys.  In the extreme case, the number of keyrings would be
> > equivalent to the number of application/software packages.
> 
> Perhaps we're not understanding each other, but my understanding of
> the above three scenarios is that they are all examples of signed
> applications where something (likely something in the kernel like IMA)
> verifies the signature on the application.  While there are going to
> be differing numbers of keys in each of the three scenarios, I believe
> they would all be on/linked-to the same usage oriented keyring as they
> all share the same usage: application signatures.

Yes they're all verifying file signatures, but the software packages are from
different sources (e.g. distro, chrome), signed by different keys.  Only a
particular key should be used to verify the file signatures for a particular
application.  The scenarios, described above, are the ratio of distro/single
entity vs. non distro/single entity signed packages, which would correspond to
the number of keyrings.

Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image,
firmware, etc).  It's a good start, but even this probably is not fine enough
granularity.

> 
> > > My takeaway from Clavis was that it was more about establishing a set
> > > of access controls around keys already present in the keyrings and my
> > > comments about usage/spplication oriented keyrings have been in that
> > > context.  While the access control policy, regardless of how it is
> > > implemented, should no doubt incorporate the trust placed in the
> > > individual keys, how that trust is established is a separate issue
> > > from access control as far as I'm concerned.
> > 
> > Clavis defined both a mechanism for establishing trust and access control rules.
> > 
> > Clavis defined a single Clavis key to establish trust.  The Clavis policy rules
> > were signed by the Clavis key.  The Clavis policy rules defined the access
> > control.
> 
> Unfortunately I think we're getting a little ambiguous with how we are
> using the word "trust".  Just as "security" can mean different things
> depending on context, so can "trust" as the qualities we are trusting
> will vary depending on context.  I'll leave it at that for now as I
> believe we are talking about different things in the paragraphs above.
> 
> Regardless, I'll also say this regarding Clavis and key/keyring access
> controls - as implemented, Clavis doesn't look like a LSM to me for
> the reasons already given.  If all of the various keys subsystem
> maintainers believe it is the Right Thing To Do inside the keys
> subsystem then it isn't my place to have a say in that.  I personally
> believe that doing the work to support usage oriented keyrings before,
> or while, implementing a Clavis-like mechanism is the better option,
> but that is a decision for you and the other key maintainers.

"Usage oriented keyrings" similarly implies any key on a particular keyring is
acceptable.  Without understanding what you mean by "usage oriented keyrings", I
would assume it would work initially, but eventually it too will not be fine
enough granularity.

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>>>>> 
>>>>> I'd still also like to see some discussion about moving towards the
>>>>> addition of keyrings oriented towards usage instead of limiting
>>>>> ourselves to keyrings that are oriented on the source of the keys.
>>>>> Perhaps I'm missing some important detail which makes this
>>>>> impractical, but it seems like an obvious improvement to me and would
>>>>> go a long way towards solving some of the problems that we typically
>>>>> see with kernel keys.
>> 
>> The intent is not to limit ourselves to the source of the key.  The main
>> point of Clavis is to allow the end-user to determine what kernel keys
>> they want to trust and for what purpose, irrespective of the originating
>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
>> go back in time, individual keyrings could be created that are oriented
>> toward usage.   The idea for introducing Clavis is to bridge what we
>> have today with kernel keys and allow them to be usage based.
> 
> While it is unlikely that the current well known keyrings could be
> removed, I see no reason why new usage oriented keyrings could not be
> introduced.  We've seen far more significant shifts in the kernel over
> the years.

Could you further clarify how a usage oriented keyring would work?  For 
example, if a kernel module keyring was added, how would the end-user
add keys to it while maintaining a root of trust?

Re: [RFC PATCH v3 00/13] Clavis LSM

[Jarkko Sakkinen]

On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > >>>
> > >>> I'd still also like to see some discussion about moving towards the
> > >>> addition of keyrings oriented towards usage instead of limiting
> > >>> ourselves to keyrings that are oriented on the source of the keys.
> > >>> Perhaps I'm missing some important detail which makes this
> > >>> impractical, but it seems like an obvious improvement to me and would
> > >>> go a long way towards solving some of the problems that we typically
> > >>> see with kernel keys.
> >
> > The intent is not to limit ourselves to the source of the key.  The main
> > point of Clavis is to allow the end-user to determine what kernel keys
> > they want to trust and for what purpose, irrespective of the originating
> > source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> > go back in time, individual keyrings could be created that are oriented
> > toward usage.   The idea for introducing Clavis is to bridge what we
> > have today with kernel keys and allow them to be usage based.
> 
> While it is unlikely that the current well known keyrings could be
> removed, I see no reason why new usage oriented keyrings could not be
> introduced.  We've seen far more significant shifts in the kernel over
> the years.

Could we implement such change in a way that these new imaginary
(at this point) usage oriented keyrings would be used to create
the "legacy" keyrings?

> 
> -- 
> paul-moore.com
> 

BR, Jarkko

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> >
> > ...
> >
> > > Ok, let's go through different scenarios to see if it would scale.
> > >
> > > Scenario 1: Mostly distro signed userspace applications, minimum number of
> > > developer, customer, 3rd party applications.
> > >
> > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> > > same party.
> > >
> > > Scenario 3: extreme case - every application signed by different party.
> > >
> > > With the minimum case, there would probably be a default key or sets of
> > > permissible keys.  In the extreme case, the number of keyrings would be
> > > equivalent to the number of application/software packages.
> >
> > Perhaps we're not understanding each other, but my understanding of
> > the above three scenarios is that they are all examples of signed
> > applications where something (likely something in the kernel like IMA)
> > verifies the signature on the application.  While there are going to
> > be differing numbers of keys in each of the three scenarios, I believe
> > they would all be on/linked-to the same usage oriented keyring as they
> > all share the same usage: application signatures.
>
> Yes they're all verifying file signatures, but the software packages are from
> different sources (e.g. distro, chrome), signed by different keys.

Yep.

> Only a
> particular key should be used to verify the file signatures for a particular
> application.

That's definitely one access control policy, but I can also envision a
scenario where I have just one keyring for application signatures with
multiple keys from multiple vendors.

> Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image,
> firmware, etc).  It's a good start, but even this probably is not fine enough
> granularity.

Which is fine, but like I said earlier, it makes far more sense to me
to move towards usage oriented keyrings and then apply whatever
additional access control granularity is required to meet a given
scenario.

It's also worth (re)mentioning that what makes Clavis not-a-LSM in my
mind is how it is implemented, not necessarily its security goals.  If
Clavis were to be implemented in such a way that it only relied on
security/LSM blobs and not keys/keyrings it might be more suitable.

> > > > My takeaway from Clavis was that it was more about establishing a set
> > > > of access controls around keys already present in the keyrings and my
> > > > comments about usage/spplication oriented keyrings have been in that
> > > > context.  While the access control policy, regardless of how it is
> > > > implemented, should no doubt incorporate the trust placed in the
> > > > individual keys, how that trust is established is a separate issue
> > > > from access control as far as I'm concerned.
> > >
> > > Clavis defined both a mechanism for establishing trust and access control rules.
> > >
> > > Clavis defined a single Clavis key to establish trust.  The Clavis policy rules
> > > were signed by the Clavis key.  The Clavis policy rules defined the access
> > > control.
> >
> > Unfortunately I think we're getting a little ambiguous with how we are
> > using the word "trust".  Just as "security" can mean different things
> > depending on context, so can "trust" as the qualities we are trusting
> > will vary depending on context.  I'll leave it at that for now as I
> > believe we are talking about different things in the paragraphs above.
> >
> > Regardless, I'll also say this regarding Clavis and key/keyring access
> > controls - as implemented, Clavis doesn't look like a LSM to me for
> > the reasons already given.  If all of the various keys subsystem
> > maintainers believe it is the Right Thing To Do inside the keys
> > subsystem then it isn't my place to have a say in that.  I personally
> > believe that doing the work to support usage oriented keyrings before,
> > or while, implementing a Clavis-like mechanism is the better option,
> > but that is a decision for you and the other key maintainers.
>
> "Usage oriented keyrings" similarly implies any key on a particular keyring is
> acceptable.

Yep.

> Without understanding what you mean by "usage oriented keyrings", I
> would assume it would work initially, but eventually it too will not be fine
> enough granularity.

It all depends on what your goals are, but like I said above, it
really seems to me like this is a good first step which can be
followed up with additional granularity.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> >>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> >>>>>
> >>>>> I'd still also like to see some discussion about moving towards the
> >>>>> addition of keyrings oriented towards usage instead of limiting
> >>>>> ourselves to keyrings that are oriented on the source of the keys.
> >>>>> Perhaps I'm missing some important detail which makes this
> >>>>> impractical, but it seems like an obvious improvement to me and would
> >>>>> go a long way towards solving some of the problems that we typically
> >>>>> see with kernel keys.
> >>
> >> The intent is not to limit ourselves to the source of the key.  The main
> >> point of Clavis is to allow the end-user to determine what kernel keys
> >> they want to trust and for what purpose, irrespective of the originating
> >> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> >> go back in time, individual keyrings could be created that are oriented
> >> toward usage.   The idea for introducing Clavis is to bridge what we
> >> have today with kernel keys and allow them to be usage based.
> >
> > While it is unlikely that the current well known keyrings could be
> > removed, I see no reason why new usage oriented keyrings could not be
> > introduced.  We've seen far more significant shifts in the kernel over
> > the years.
>
> Could you further clarify how a usage oriented keyring would work?  For
> example, if a kernel module keyring was added, how would the end-user
> add keys to it while maintaining a root of trust?

Consider it an exercise left to the reader :)

I imagine there are different ways one could do that, either using
traditional user/group/capability permissions and/or LSM permissions,
it would depend on the environment and the security goals of the
overall system.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > >>>
> > > >>> I'd still also like to see some discussion about moving towards the
> > > >>> addition of keyrings oriented towards usage instead of limiting
> > > >>> ourselves to keyrings that are oriented on the source of the keys.
> > > >>> Perhaps I'm missing some important detail which makes this
> > > >>> impractical, but it seems like an obvious improvement to me and would
> > > >>> go a long way towards solving some of the problems that we typically
> > > >>> see with kernel keys.
> > >
> > > The intent is not to limit ourselves to the source of the key.  The main
> > > point of Clavis is to allow the end-user to determine what kernel keys
> > > they want to trust and for what purpose, irrespective of the originating
> > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> > > go back in time, individual keyrings could be created that are oriented
> > > toward usage.   The idea for introducing Clavis is to bridge what we
> > > have today with kernel keys and allow them to be usage based.
> >
> > While it is unlikely that the current well known keyrings could be
> > removed, I see no reason why new usage oriented keyrings could not be
> > introduced.  We've seen far more significant shifts in the kernel over
> > the years.
>
> Could we implement such change in a way that these new imaginary
> (at this point) usage oriented keyrings would be used to create
> the "legacy" keyrings?

I think it would be easier for them to coexist so that one could have
an easier migration.  It's possible that even once everything was
migrated to the new usage oriented keyrings it would still make sense
to keep the existing keyrings in place and always link keys from there
to the newer usage keyrings.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Jarkko Sakkinen]

On Tue, Mar 04, 2025 at 07:25:13PM -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > > > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > > >>>
> > > > >>> I'd still also like to see some discussion about moving towards the
> > > > >>> addition of keyrings oriented towards usage instead of limiting
> > > > >>> ourselves to keyrings that are oriented on the source of the keys.
> > > > >>> Perhaps I'm missing some important detail which makes this
> > > > >>> impractical, but it seems like an obvious improvement to me and would
> > > > >>> go a long way towards solving some of the problems that we typically
> > > > >>> see with kernel keys.
> > > >
> > > > The intent is not to limit ourselves to the source of the key.  The main
> > > > point of Clavis is to allow the end-user to determine what kernel keys
> > > > they want to trust and for what purpose, irrespective of the originating
> > > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> > > > go back in time, individual keyrings could be created that are oriented
> > > > toward usage.   The idea for introducing Clavis is to bridge what we
> > > > have today with kernel keys and allow them to be usage based.
> > >
> > > While it is unlikely that the current well known keyrings could be
> > > removed, I see no reason why new usage oriented keyrings could not be
> > > introduced.  We've seen far more significant shifts in the kernel over
> > > the years.
> >
> > Could we implement such change in a way that these new imaginary
> > (at this point) usage oriented keyrings would be used to create
> > the "legacy" keyrings?
> 
> I think it would be easier for them to coexist so that one could have
> an easier migration.  It's possible that even once everything was
> migrated to the new usage oriented keyrings it would still make sense
> to keep the existing keyrings in place and always link keys from there
> to the newer usage keyrings.

OK, so here I agree and disagree:

1. It probably does not port everything.
2. Still, we need to be sure that "can be done" condition is satisfied
   for the sake of robustness.


> 
> -- 
> paul-moore.com
> 

BR, Jarkko

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > 
> > > ...
> > > 
> > > > Ok, let's go through different scenarios to see if it would scale.
> > > > 
> > > > Scenario 1: Mostly distro signed userspace applications, minimum number of
> > > > developer, customer, 3rd party applications.
> > > > 
> > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> > > > same party.
> > > > 
> > > > Scenario 3: extreme case - every application signed by different party.
> > > > 
> > > > With the minimum case, there would probably be a default key or sets of
> > > > permissible keys.  In the extreme case, the number of keyrings would be
> > > > equivalent to the number of application/software packages.
> > > 
> > > Perhaps we're not understanding each other, but my understanding of
> > > the above three scenarios is that they are all examples of signed
> > > applications where something (likely something in the kernel like IMA)
> > > verifies the signature on the application.  While there are going to
> > > be differing numbers of keys in each of the three scenarios, I believe
> > > they would all be on/linked-to the same usage oriented keyring as they
> > > all share the same usage: application signatures.
> > 
> > Yes they're all verifying file signatures, but the software packages are from
> > different sources (e.g. distro, chrome), signed by different keys.
> 
> Yep.
> 
> > Only a
> > particular key should be used to verify the file signatures for a particular
> > application.
> 
> That's definitely one access control policy, but I can also envision a
> scenario where I have just one keyring for application signatures with
> multiple keys from multiple vendors.

Having a single keyring with keys from multiple software vendors is the status
quo.

> 
> > Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image,
> > firmware, etc).  It's a good start, but even this probably is not fine enough
> > granularity.
> 
> Which is fine, but like I said earlier, it makes far more sense to me
> to move towards usage oriented keyrings and then apply whatever
> additional access control granularity is required to meet a given
> scenario.

Since you didn't agree with my example of "usage oriented keyrings", please
provide an example.

> 
> It's also worth (re)mentioning that what makes Clavis not-a-LSM in my
> mind is how it is implemented, not necessarily its security goals.  If
> Clavis were to be implemented in such a way that it only relied on
> security/LSM blobs and not keys/keyrings it might be more suitable.
> 
> > > > > My takeaway from Clavis was that it was more about establishing a set
> > > > > of access controls around keys already present in the keyrings and my
> > > > > comments about usage/spplication oriented keyrings have been in that
> > > > > context.  While the access control policy, regardless of how it is
> > > > > implemented, should no doubt incorporate the trust placed in the
> > > > > individual keys, how that trust is established is a separate issue
> > > > > from access control as far as I'm concerned.
> > > > 
> > > > Clavis defined both a mechanism for establishing trust and access control rules.
> > > > 
> > > > Clavis defined a single Clavis key to establish trust.  The Clavis policy rules
> > > > were signed by the Clavis key.  The Clavis policy rules defined the access
> > > > control.
> > > 
> > > Unfortunately I think we're getting a little ambiguous with how we are
> > > using the word "trust".  Just as "security" can mean different things
> > > depending on context, so can "trust" as the qualities we are trusting
> > > will vary depending on context.  I'll leave it at that for now as I
> > > believe we are talking about different things in the paragraphs above.
> > > 
> > > Regardless, I'll also say this regarding Clavis and key/keyring access
> > > controls - as implemented, Clavis doesn't look like a LSM to me for
> > > the reasons already given.  If all of the various keys subsystem
> > > maintainers believe it is the Right Thing To Do inside the keys
> > > subsystem then it isn't my place to have a say in that.  I personally
> > > believe that doing the work to support usage oriented keyrings before,
> > > or while, implementing a Clavis-like mechanism is the better option,
> > > but that is a decision for you and the other key maintainers.
> > 
> > "Usage oriented keyrings" similarly implies any key on a particular keyring is
> > acceptable.
> 
> Yep.
> 
> > Without understanding what you mean by "usage oriented keyrings", I
> > would assume it would work initially, but eventually it too will not be fine
> > enough granularity.
> 
> It all depends on what your goals are, but like I said above, it
> really seems to me like this is a good first step which can be
> followed up with additional granularity.

Without a concrete example of "usage oriented keyrings", it's hard to understand
why "additional" granularity should be deferred.  From my perspective,
"additional" granularity is the main issue.

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > >
> > > > ...
> > > >
> > > > > Ok, let's go through different scenarios to see if it would scale.
> > > > >
> > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of
> > > > > developer, customer, 3rd party applications.
> > > > >
> > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> > > > > same party.
> > > > >
> > > > > Scenario 3: extreme case - every application signed by different party.
> > > > >
> > > > > With the minimum case, there would probably be a default key or sets of
> > > > > permissible keys.  In the extreme case, the number of keyrings would be
> > > > > equivalent to the number of application/software packages.
> > > >
> > > > Perhaps we're not understanding each other, but my understanding of
> > > > the above three scenarios is that they are all examples of signed
> > > > applications where something (likely something in the kernel like IMA)
> > > > verifies the signature on the application.  While there are going to
> > > > be differing numbers of keys in each of the three scenarios, I believe
> > > > they would all be on/linked-to the same usage oriented keyring as they
> > > > all share the same usage: application signatures.
> > >
> > > Yes they're all verifying file signatures, but the software packages are from
> > > different sources (e.g. distro, chrome), signed by different keys.
> >
> > Yep.
> >
> > > Only a
> > > particular key should be used to verify the file signatures for a particular
> > > application.
> >
> > That's definitely one access control policy, but I can also envision a
> > scenario where I have just one keyring for application signatures with
> > multiple keys from multiple vendors.
>
> Having a single keyring with keys from multiple software vendors is the status
> quo.

A single keyring with keys from multiple vendors does happen today
yes, but there is no separation based on how those keys are used, e.g.
separate application signature and kernel module signature keyrings.

> > > Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image,
> > > firmware, etc).  It's a good start, but even this probably is not fine enough
> > > granularity.
> >
> > Which is fine, but like I said earlier, it makes far more sense to me
> > to move towards usage oriented keyrings and then apply whatever
> > additional access control granularity is required to meet a given
> > scenario.
>
> Since you didn't agree with my example of "usage oriented keyrings", please
> provide an example.

I have.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Mimi Zohar]

On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote:
> On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > > > 
> > > > > ...
> > > > > 
> > > > > > Ok, let's go through different scenarios to see if it would scale.
> > > > > > 
> > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of
> > > > > > developer, customer, 3rd party applications.
> > > > > > 
> > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> > > > > > same party.
> > > > > > 
> > > > > > Scenario 3: extreme case - every application signed by different party.
> > > > > > 
> > > > > > With the minimum case, there would probably be a default key or sets of
> > > > > > permissible keys.  In the extreme case, the number of keyrings would be
> > > > > > equivalent to the number of application/software packages.
> > > > > 
> > > > > Perhaps we're not understanding each other, but my understanding of
> > > > > the above three scenarios is that they are all examples of signed
> > > > > applications where something (likely something in the kernel like IMA)
> > > > > verifies the signature on the application.  While there are going to
> > > > > be differing numbers of keys in each of the three scenarios, I believe
> > > > > they would all be on/linked-to the same usage oriented keyring as they
> > > > > all share the same usage: application signatures.
> > > > 
> > > > Yes they're all verifying file signatures, but the software packages are from
> > > > different sources (e.g. distro, chrome), signed by different keys.
> > > 
> > > Yep.
> > > 
> > > > Only a
> > > > particular key should be used to verify the file signatures for a particular
> > > > application.
> > > 
> > > That's definitely one access control policy, but I can also envision a
> > > scenario where I have just one keyring for application signatures with
> > > multiple keys from multiple vendors.
> > 
> > Having a single keyring with keys from multiple software vendors is the status
> > quo.
> 
> A single keyring with keys from multiple vendors does happen today
> yes, but there is no separation based on how those keys are used, e.g.
> separate application signature and kernel module signature keyrings.

As soon as you add multiple vendors keys on the kernel module signature keyring,
you'll need finer grained access control.

Mimi

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Tue, Mar 4, 2025 at 9:20 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote:
> > On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote:
> > > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote:
> > > > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote:
> > > > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> > > > > >
> > > > > > ...
> > > > > >
> > > > > > > Ok, let's go through different scenarios to see if it would scale.
> > > > > > >
> > > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of
> > > > > > > developer, customer, 3rd party applications.
> > > > > > >
> > > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the
> > > > > > > same party.
> > > > > > >
> > > > > > > Scenario 3: extreme case - every application signed by different party.
> > > > > > >
> > > > > > > With the minimum case, there would probably be a default key or sets of
> > > > > > > permissible keys.  In the extreme case, the number of keyrings would be
> > > > > > > equivalent to the number of application/software packages.
> > > > > >
> > > > > > Perhaps we're not understanding each other, but my understanding of
> > > > > > the above three scenarios is that they are all examples of signed
> > > > > > applications where something (likely something in the kernel like IMA)
> > > > > > verifies the signature on the application.  While there are going to
> > > > > > be differing numbers of keys in each of the three scenarios, I believe
> > > > > > they would all be on/linked-to the same usage oriented keyring as they
> > > > > > all share the same usage: application signatures.
> > > > >
> > > > > Yes they're all verifying file signatures, but the software packages are from
> > > > > different sources (e.g. distro, chrome), signed by different keys.
> > > >
> > > > Yep.
> > > >
> > > > > Only a
> > > > > particular key should be used to verify the file signatures for a particular
> > > > > application.
> > > >
> > > > That's definitely one access control policy, but I can also envision a
> > > > scenario where I have just one keyring for application signatures with
> > > > multiple keys from multiple vendors.
> > >
> > > Having a single keyring with keys from multiple software vendors is the status
> > > quo.
> >
> > A single keyring with keys from multiple vendors does happen today
> > yes, but there is no separation based on how those keys are used, e.g.
> > separate application signature and kernel module signature keyrings.
>
> As soon as you add multiple vendors keys on the kernel module signature keyring,
> you'll need finer grained access control.

Maybe.  It depends on your security policy, some solutions might be
okay with keyring level access control granularity, others may want
finer grained control.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>>>>>>> 
>>>>>>> I'd still also like to see some discussion about moving towards the
>>>>>>> addition of keyrings oriented towards usage instead of limiting
>>>>>>> ourselves to keyrings that are oriented on the source of the keys.
>>>>>>> Perhaps I'm missing some important detail which makes this
>>>>>>> impractical, but it seems like an obvious improvement to me and would
>>>>>>> go a long way towards solving some of the problems that we typically
>>>>>>> see with kernel keys.
>>>> 
>>>> The intent is not to limit ourselves to the source of the key.  The main
>>>> point of Clavis is to allow the end-user to determine what kernel keys
>>>> they want to trust and for what purpose, irrespective of the originating
>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
>>>> go back in time, individual keyrings could be created that are oriented
>>>> toward usage.   The idea for introducing Clavis is to bridge what we
>>>> have today with kernel keys and allow them to be usage based.
>>> 
>>> While it is unlikely that the current well known keyrings could be
>>> removed, I see no reason why new usage oriented keyrings could not be
>>> introduced.  We've seen far more significant shifts in the kernel over
>>> the years.
>> 
>> Could you further clarify how a usage oriented keyring would work?  For
>> example, if a kernel module keyring was added, how would the end-user
>> add keys to it while maintaining a root of trust?
> 
> Consider it an exercise left to the reader :)
> 
> I imagine there are different ways one could do that, either using
> traditional user/group/capability permissions and/or LSM permissions,
> it would depend on the environment and the security goals of the
> overall system.

These keys are used by the Lockdown LSM to provide signature 
validation.

I realize the contents that follow in this paragraph is outside the 
boundary of mainline kernel code.  Every distro that wants their 
shim signed must explain how their kernel enforces lockdown 
mode.  The minimum requirement is lockdown in integrity mode.  
Also, the expectation is lockdown enforcement continues on 
through a kexec.

When in lockdown integrity mode, features that allow the kernel 
to be modified at runtime are disabled.  How would what you have 
suggested above adhere to these goals?

The point of the Clavis LSM is to use the root of trust provided to 
the kernel prior to it booting. This maintains the lockdown integrity 
goals, while also giving the end-user the ability to determine how 
kernel keys are used.

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote:
> > On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
> >>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
> >>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
> >>>>>>>
> >>>>>>> I'd still also like to see some discussion about moving towards the
> >>>>>>> addition of keyrings oriented towards usage instead of limiting
> >>>>>>> ourselves to keyrings that are oriented on the source of the keys.
> >>>>>>> Perhaps I'm missing some important detail which makes this
> >>>>>>> impractical, but it seems like an obvious improvement to me and would
> >>>>>>> go a long way towards solving some of the problems that we typically
> >>>>>>> see with kernel keys.
> >>>>
> >>>> The intent is not to limit ourselves to the source of the key.  The main
> >>>> point of Clavis is to allow the end-user to determine what kernel keys
> >>>> they want to trust and for what purpose, irrespective of the originating
> >>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
> >>>> go back in time, individual keyrings could be created that are oriented
> >>>> toward usage.   The idea for introducing Clavis is to bridge what we
> >>>> have today with kernel keys and allow them to be usage based.
> >>>
> >>> While it is unlikely that the current well known keyrings could be
> >>> removed, I see no reason why new usage oriented keyrings could not be
> >>> introduced.  We've seen far more significant shifts in the kernel over
> >>> the years.
> >>
> >> Could you further clarify how a usage oriented keyring would work?  For
> >> example, if a kernel module keyring was added, how would the end-user
> >> add keys to it while maintaining a root of trust?
> >
> > Consider it an exercise left to the reader :)
> >
> > I imagine there are different ways one could do that, either using
> > traditional user/group/capability permissions and/or LSM permissions,
> > it would depend on the environment and the security goals of the
> > overall system.
>
> These keys are used by the Lockdown LSM to provide signature
> validation.
>
> I realize the contents that follow in this paragraph is outside the
> boundary of mainline kernel code.  Every distro that wants their
> shim signed must explain how their kernel enforces lockdown
> mode.  The minimum requirement is lockdown in integrity mode.
> Also, the expectation is lockdown enforcement continues on
> through a kexec.

I personally find it very amusing the UEFI Secure Boot shim is reliant
on an unmaintained and only marginally supported LSM, Lockdown.  Has
anyone recently verified that Lockdown's protections are still intact
and comprehensive enough to be worthwhile?  Sorry, this is a bit of a
digression, but since you were the one to bring up Lockdown I thought
it would be important to mention that I don't have much faith that it
is still working to the same level as it originally was intended.  I
have a TODO list item to draft a policy around deprecating
unmaintained LSMs after an extended period of time, and once that is
in place if we don't have a qualified maintainer for Lockdown it will
likely fall into the deprecation process (whatever that may be).

> When in lockdown integrity mode, features that allow the kernel
> to be modified at runtime are disabled.  How would what you have
> suggested above adhere to these goals?

For starters, verify that Lockdown is still comprehensive enough to
satisfy these requirements on a modern Linux kernel.  After that has
been done, find someone with some kernel experience to step up and
maintain Lockdown.  Finally, put a mechanism in place so that
someone/something is regularly evaluating changes in the upstream
kernel to ensure that Lockdown is still able to achieve its security
goals.

After all that, then you can start worrying about keys.

> The point of the Clavis LSM is to use the root of trust provided to
> the kernel prior to it booting. This maintains the lockdown integrity
> goals, while also giving the end-user the ability to determine how
> kernel keys are used.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
>>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>>>>>>>>> 
>>>>>>>>> I'd still also like to see some discussion about moving towards the
>>>>>>>>> addition of keyrings oriented towards usage instead of limiting
>>>>>>>>> ourselves to keyrings that are oriented on the source of the keys.
>>>>>>>>> Perhaps I'm missing some important detail which makes this
>>>>>>>>> impractical, but it seems like an obvious improvement to me and would
>>>>>>>>> go a long way towards solving some of the problems that we typically
>>>>>>>>> see with kernel keys.
>>>>>> 
>>>>>> The intent is not to limit ourselves to the source of the key.  The main
>>>>>> point of Clavis is to allow the end-user to determine what kernel keys
>>>>>> they want to trust and for what purpose, irrespective of the originating
>>>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
>>>>>> go back in time, individual keyrings could be created that are oriented
>>>>>> toward usage.   The idea for introducing Clavis is to bridge what we
>>>>>> have today with kernel keys and allow them to be usage based.
>>>>> 
>>>>> While it is unlikely that the current well known keyrings could be
>>>>> removed, I see no reason why new usage oriented keyrings could not be
>>>>> introduced.  We've seen far more significant shifts in the kernel over
>>>>> the years.
>>>> 
>>>> Could you further clarify how a usage oriented keyring would work?  For
>>>> example, if a kernel module keyring was added, how would the end-user
>>>> add keys to it while maintaining a root of trust?
>>> 
>>> Consider it an exercise left to the reader :)
>>> 
>>> I imagine there are different ways one could do that, either using
>>> traditional user/group/capability permissions and/or LSM permissions,
>>> it would depend on the environment and the security goals of the
>>> overall system.
>> 
>> These keys are used by the Lockdown LSM to provide signature
>> validation.
>> 
>> I realize the contents that follow in this paragraph is outside the
>> boundary of mainline kernel code.  Every distro that wants their
>> shim signed must explain how their kernel enforces lockdown
>> mode.  The minimum requirement is lockdown in integrity mode.
>> Also, the expectation is lockdown enforcement continues on
>> through a kexec.
> 
> I personally find it very amusing the UEFI Secure Boot shim is reliant
> on an unmaintained and only marginally supported LSM, Lockdown.  Has
> anyone recently verified that Lockdown's protections are still intact
> and comprehensive enough to be worthwhile?  Sorry, this is a bit of a
> digression, but since you were the one to bring up Lockdown I thought
> it would be important to mention that I don't have much faith that it
> is still working to the same level as it originally was intended.  I
> have a TODO list item to draft a policy around deprecating
> unmaintained LSMs after an extended period of time, and once that is
> in place if we don't have a qualified maintainer for Lockdown it will
> likely fall into the deprecation process (whatever that may be).

Does this mean Microsoft will begin signing shims in the future without 
the lockdown requirement?

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@paul-moore.com> wrote:
>>
>> On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> 
>>>>>> wrote:
>>>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>>>>>>>>>>
>>>>>>>>>> I'd still also like to see some discussion about moving towards the
>>>>>>>>>> addition of keyrings oriented towards usage instead of limiting
>>>>>>>>>> ourselves to keyrings that are oriented on the source of the keys.
>>>>>>>>>> Perhaps I'm missing some important detail which makes this
>>>>>>>>>> impractical, but it seems like an obvious improvement to me and would
>>>>>>>>>> go a long way towards solving some of the problems that we typically
>>>>>>>>>> see with kernel keys.
>>>>>>>
>>>>>>> The intent is not to limit ourselves to the source of the key.  The main
>>>>>>> point of Clavis is to allow the end-user to determine what kernel keys
>>>>>>> they want to trust and for what purpose, irrespective of the originating
>>>>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
>>>>>>> go back in time, individual keyrings could be created that are oriented
>>>>>>> toward usage.   The idea for introducing Clavis is to bridge what we
>>>>>>> have today with kernel keys and allow them to be usage based.
>>>>>>
>>>>>> While it is unlikely that the current well known keyrings could be
>>>>>> removed, I see no reason why new usage oriented keyrings could not be
>>>>>> introduced.  We've seen far more significant shifts in the kernel over
>>>>>> the years.
>>>>>
>>>>> Could you further clarify how a usage oriented keyring would work?  For
>>>>> example, if a kernel module keyring was added, how would the end-user
>>>>> add keys to it while maintaining a root of trust?
>>>>
>>>> Consider it an exercise left to the reader :)
>>>>
>>>> I imagine there are different ways one could do that, either using
>>>> traditional user/group/capability permissions and/or LSM permissions,
>>>> it would depend on the environment and the security goals of the
>>>> overall system.
>>>
>>> These keys are used by the Lockdown LSM to provide signature
>>> validation.
>>>
>>> I realize the contents that follow in this paragraph is outside the
>>> boundary of mainline kernel code.  Every distro that wants their
>>> shim signed must explain how their kernel enforces lockdown
>>> mode.  The minimum requirement is lockdown in integrity mode.
>>> Also, the expectation is lockdown enforcement continues on
>>> through a kexec.
>>
>> I personally find it very amusing the UEFI Secure Boot shim is reliant
>> on an unmaintained and only marginally supported LSM, Lockdown.  Has
>> anyone recently verified that Lockdown's protections are still intact
>> and comprehensive enough to be worthwhile?  Sorry, this is a bit of a
>> digression, but since you were the one to bring up Lockdown I thought
>> it would be important to mention that I don't have much faith that it
>> is still working to the same level as it originally was intended.  I
>> have a TODO list item to draft a policy around deprecating
>> unmaintained LSMs after an extended period of time, and once that is
>> in place if we don't have a qualified maintainer for Lockdown it will
>> likely fall into the deprecation process (whatever that may be).
>
> Does this mean Microsoft will begin signing shims in the future without
> the lockdown requirement?

That's not a question I can answer, you'll need to discuss that with the 
UEFI SB people.

--
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> 
>>> On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote:
>>>>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I'd still also like to see some discussion about moving towards the
>>>>>>>>>>> addition of keyrings oriented towards usage instead of limiting
>>>>>>>>>>> ourselves to keyrings that are oriented on the source of the keys.
>>>>>>>>>>> Perhaps I'm missing some important detail which makes this
>>>>>>>>>>> impractical, but it seems like an obvious improvement to me and would
>>>>>>>>>>> go a long way towards solving some of the problems that we typically
>>>>>>>>>>> see with kernel keys.
>>>>>>>> 
>>>>>>>> The intent is not to limit ourselves to the source of the key.  The main
>>>>>>>> point of Clavis is to allow the end-user to determine what kernel keys
>>>>>>>> they want to trust and for what purpose, irrespective of the originating
>>>>>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could
>>>>>>>> go back in time, individual keyrings could be created that are oriented
>>>>>>>> toward usage.   The idea for introducing Clavis is to bridge what we
>>>>>>>> have today with kernel keys and allow them to be usage based.
>>>>>>> 
>>>>>>> While it is unlikely that the current well known keyrings could be
>>>>>>> removed, I see no reason why new usage oriented keyrings could not be
>>>>>>> introduced.  We've seen far more significant shifts in the kernel over
>>>>>>> the years.
>>>>>> 
>>>>>> Could you further clarify how a usage oriented keyring would work?  For
>>>>>> example, if a kernel module keyring was added, how would the end-user
>>>>>> add keys to it while maintaining a root of trust?
>>>>> 
>>>>> Consider it an exercise left to the reader :)
>>>>> 
>>>>> I imagine there are different ways one could do that, either using
>>>>> traditional user/group/capability permissions and/or LSM permissions,
>>>>> it would depend on the environment and the security goals of the
>>>>> overall system.
>>>> 
>>>> These keys are used by the Lockdown LSM to provide signature
>>>> validation.
>>>> 
>>>> I realize the contents that follow in this paragraph is outside the
>>>> boundary of mainline kernel code.  Every distro that wants their
>>>> shim signed must explain how their kernel enforces lockdown
>>>> mode.  The minimum requirement is lockdown in integrity mode.
>>>> Also, the expectation is lockdown enforcement continues on
>>>> through a kexec.
>>> 
>>> I personally find it very amusing the UEFI Secure Boot shim is reliant
>>> on an unmaintained and only marginally supported LSM, Lockdown.  Has
>>> anyone recently verified that Lockdown's protections are still intact
>>> and comprehensive enough to be worthwhile?  Sorry, this is a bit of a
>>> digression, but since you were the one to bring up Lockdown I thought
>>> it would be important to mention that I don't have much faith that it
>>> is still working to the same level as it originally was intended.  I
>>> have a TODO list item to draft a policy around deprecating
>>> unmaintained LSMs after an extended period of time, and once that is
>>> in place if we don't have a qualified maintainer for Lockdown it will
>>> likely fall into the deprecation process (whatever that may be).
>> 
>> Does this mean Microsoft will begin signing shims in the future without
>> the lockdown requirement?
> 
> That's not a question I can answer, you'll need to discuss that with the UEFI SB people.

Based on your previous lockdown comments, I thought you might have 
some new information.  Having lockdown enforcement has always been 
a requirement to get a shim signed by Microsoft. 

The alternative "usage-oriented keyring" approach you've suggested 
wouldn't align with the threat model that lockdown aims to achieve.  For 
a distro-based kernel, I don't see the value in pursuing such an approach. 
For someone compiling their own kernel and not using a distro kernel, 
they could compile in their own keys.  With Clavis, I attempted to develop 
an approach that would meet the lockdown threat model requirements 
while allowing the end user to control key usage as they deem fit.

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@paul-moore.com> wrote:
> > On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:

...

> >> Does this mean Microsoft will begin signing shims in the future without
> >> the lockdown requirement?
> >
> > That's not a question I can answer, you'll need to discuss that with the UEFI SB people.
>
> Based on your previous lockdown comments, I thought you might have
> some new information.  Having lockdown enforcement has always been
> a requirement to get a shim signed by Microsoft.

I want to address two things, the first, and most important, is that
while I am currently employed by Microsoft, I do not speak for
Microsoft and the decisions and actions I take as an upstream Linux
kernel maintainer are not vetted by Microsoft in any way.  I think you
will find that many upstream kernel maintainers operate in a similar
way for a variety of very good reasons.

The second issue is that my main focus is on ensuring we have a
secure, safe, and well maintained LSM subsystem within the upstream
Linux kernel.  While I do care about downstream efforts, e.g. UEFI
Secure Boot, those efforts are largely outside the scope of the
upstream Linux kernel and not my first concern.  If the developer
groups who are focused on things like UEFI SB want to rely on
functionality within the upstream Linux kernel they should be prepared
to stand up and contribute/maintain those features or else they may go
away at some point in the future.  In very blunt terms, contribute
upstream or Lockdown dies.

However, let me be clear that I consider deprecation and removal of a
LSM to be an option of last resort.  My preference would be to find a
capable maintainer, or two, that would be willing to take on a
maintenance role for the LSM in question.  Luckily I think we may have
some people who are interested in doing so for the Lockdown LSM,
hopefully you'll see something on-list in the near future.

> The alternative "usage-oriented keyring" approach you've suggested
> wouldn't align with the threat model that lockdown aims to achieve.

That's a Lockdown problem, or more specifically a problem for the
people who are freeloading on the Lockdown LSM and expecting it to be
maintained without contributing anything meaningful.

> For
> a distro-based kernel, I don't see the value in pursuing such an approach.

So you've said.  I disagree, but we've already had that discussion,
let's agree to not waste any more time repeating ourselves.

> With Clavis, I attempted to develop
> an approach that would meet the lockdown threat model requirements
> while allowing the end user to control key usage as they deem fit.

As mentioned previously, the design/implementation choices you made
for Clavis means it is better suited for inclusion in the key
subsystem and not as a standalone LSM.  If you wanted to
redesign/rework Clavis to stick to the traditional LSM security blobs
perhaps that is something we could consider as a LSM, but it's
probably worth seeing if David and Jarkko have any interest in
including Clavis functionality in the key subsystem first.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[James Bottomley]

On Thu, 2025-03-20 at 16:24 +0000, Eric Snowberg wrote:
> Having lockdown enforcement has always been 
> a requirement to get a shim signed by Microsoft.

This is factually incorrect.  Microsoft transferred shim signing to an
independent process run by a group of open source maintainers a while
ago:

https://github.com/rhboot/shim-review/

If you actually look, you'll see even Microsoft has to obey this
upstream process for their Linux distro:

https://github.com/rhboot/shim-review/issues/427

Regards,

James

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 20, 2025, at 3:36 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>> On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> 
> ...
> 
>>>> Does this mean Microsoft will begin signing shims in the future without
>>>> the lockdown requirement?
>>> 
>>> That's not a question I can answer, you'll need to discuss that with the UEFI SB people.
>> 
>> Based on your previous lockdown comments, I thought you might have
>> some new information.  Having lockdown enforcement has always been
>> a requirement to get a shim signed by Microsoft.

...

> 
>> The alternative "usage-oriented keyring" approach you've suggested
>> wouldn't align with the threat model that lockdown aims to achieve.
> 
> That's a Lockdown problem, or more specifically a problem for the
> people who are freeloading on the Lockdown LSM and expecting it to be
> maintained without contributing anything meaningful.

There are past examples of previous contributions, but they don't seem to 
go anywhere:

https://lkml.org/lkml/2023/5/26/1057

Which causes us to carry patches like this downstream.

> 
>> With Clavis, I attempted to develop
>> an approach that would meet the lockdown threat model requirements
>> while allowing the end user to control key usage as they deem fit.
> 
> As mentioned previously, the design/implementation choices you made
> for Clavis means it is better suited for inclusion in the key
> subsystem and not as a standalone LSM.  If you wanted to
> redesign/rework Clavis to stick to the traditional LSM security blobs
> perhaps that is something we could consider as a LSM, but it's
> probably worth seeing if David and Jarkko have any interest in
> including Clavis functionality in the key subsystem first.

The direction of creating a new LSM was based on this discussion:

https://lkml.org/lkml/2023/10/5/312

A lot of time could have been saved had your concerns been 
voiced in either the first or second round.  If David or Jarkko are 
interested in a non LSM version, I can work on that.  

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 20, 2025, at 4:40 PM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> On Thu, 2025-03-20 at 16:24 +0000, Eric Snowberg wrote:
>> Having lockdown enforcement has always been 
>> a requirement to get a shim signed by Microsoft.
> 
> This is factually incorrect.  Microsoft transferred shim signing to an
> independent process run by a group of open source maintainers a while
> ago:

Yes, the shim-review process is understood.  I'm not sure how my sentence 
is factually incorrect though. Unless you are saying Microsoft no longer 
maintains the private key.  Hopefully that is not the case, since the public 
key ships on just about every single PC built.

Re: [RFC PATCH v3 00/13] Clavis LSM

[James Bottomley]

On Fri, 2025-03-21 at 16:40 +0000, Eric Snowberg wrote:
> > On Mar 20, 2025, at 4:40 PM, James Bottomley
> > <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > On Thu, 2025-03-20 at 16:24 +0000, Eric Snowberg wrote:
> > > Having lockdown enforcement has always been 
> > > a requirement to get a shim signed by Microsoft.
> > 
> > This is factually incorrect.  Microsoft transferred shim signing to
> > an independent process run by a group of open source maintainers a
> > while ago:
> 
> Yes, the shim-review process is understood.  I'm not sure how my
> sentence  is factually incorrect though.

You said people "get shim signed by Microsoft".  They don't, they get
it signed by the key held by the shim-review maintainers.

>  Unless you are saying Microsoft no longer  maintains the private
> key.

Well technically the private key is owned by UEFI (and referred to as
the UEFI CA) but there are multiple HSM based copies floating around
under the control of various operating system groups.  The Windows OS
group holds one and the shim-review group holds another ... there are
probably other copies I don't know about, though.

The point about this is that UEFI co-ordinates various discussions
between the private key holders about how to preserve security in the
UEFI boot environment (mostly at the UEFI Security Sub Team level) it's
no longer something Microsoft uniquely decides.

>   Hopefully that is not the case, since the public  key ships on just
> about every single PC built.

I don't understand why Microsoft no-longer owning the private key is a
problem?  Only the public key ships on PCs and that hasn't changed (at
least not yet, it might have to for NIST requirements since RSA2048 is
being deprecated).

Regards,

James

Re: [RFC PATCH v3 00/13] Clavis LSM

[Jarkko Sakkinen]

On Thu, Mar 20, 2025 at 06:40:55PM -0400, James Bottomley wrote:
> On Thu, 2025-03-20 at 16:24 +0000, Eric Snowberg wrote:
> > Having lockdown enforcement has always been 
> > a requirement to get a shim signed by Microsoft.
> 
> This is factually incorrect.  Microsoft transferred shim signing to an
> independent process run by a group of open source maintainers a while
> ago:
> 
> https://github.com/rhboot/shim-review/
> 
> If you actually look, you'll see even Microsoft has to obey this
> upstream process for their Linux distro:
> 
> https://github.com/rhboot/shim-review/issues/427

I did not know this. Thanks for educating!

> 
> Regards,
> 
> James
> 

BR, Jarkko

Re: [RFC PATCH v3 00/13] Clavis LSM

[Jarkko Sakkinen]

On Thu, Mar 20, 2025 at 05:36:41PM -0400, Paul Moore wrote:
> On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > > On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> 
> ...
> 
> > >> Does this mean Microsoft will begin signing shims in the future without
> > >> the lockdown requirement?
> > >
> > > That's not a question I can answer, you'll need to discuss that with the UEFI SB people.
> >
> > Based on your previous lockdown comments, I thought you might have
> > some new information.  Having lockdown enforcement has always been
> > a requirement to get a shim signed by Microsoft.
> 
> I want to address two things, the first, and most important, is that
> while I am currently employed by Microsoft, I do not speak for
> Microsoft and the decisions and actions I take as an upstream Linux
> kernel maintainer are not vetted by Microsoft in any way.  I think you
> will find that many upstream kernel maintainers operate in a similar
> way for a variety of very good reasons.

This is understood. If one takes a kernel maintainer role, one should
unconditionally disobey any vetting by the employer (even at the cost of
the job, or alternatively at the cost of giving up the maintainership).

And with you in particular I don't think anyone has any trust issues,
no matter which group of villains you might be employed by ;-)

> 
> The second issue is that my main focus is on ensuring we have a
> secure, safe, and well maintained LSM subsystem within the upstream
> Linux kernel.  While I do care about downstream efforts, e.g. UEFI
> Secure Boot, those efforts are largely outside the scope of the
> upstream Linux kernel and not my first concern.  If the developer
> groups who are focused on things like UEFI SB want to rely on
> functionality within the upstream Linux kernel they should be prepared
> to stand up and contribute/maintain those features or else they may go
> away at some point in the future.  In very blunt terms, contribute
> upstream or Lockdown dies.

Could Lockdown functionality be re-implemented with that eBPF LSM? I
have not really looked into it so far...

BR, Jarkko

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Mar 21, 2025 at 12:37 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Mar 20, 2025, at 3:36 PM, Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >>> On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@paul-moore.com> wrote:
> >>> On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> >
> > ...
> >
> >>>> Does this mean Microsoft will begin signing shims in the future without
> >>>> the lockdown requirement?
> >>>
> >>> That's not a question I can answer, you'll need to discuss that with the UEFI SB people.
> >>
> >> Based on your previous lockdown comments, I thought you might have
> >> some new information.  Having lockdown enforcement has always been
> >> a requirement to get a shim signed by Microsoft.
>
> ...
>
> >> The alternative "usage-oriented keyring" approach you've suggested
> >> wouldn't align with the threat model that lockdown aims to achieve.
> >
> > That's a Lockdown problem, or more specifically a problem for the
> > people who are freeloading on the Lockdown LSM and expecting it to be
> > maintained without contributing anything meaningful.
>
> There are past examples of previous contributions, but they don't seem to
> go anywhere:
>
> https://lkml.org/lkml/2023/5/26/1057

Those patches proposed loosening Lockdown restrictions, which is
particularly concerning given the intent behind Lockdown, and
considering the author did not have any existing patches under
security/ (they still do not, I just checked) there was room for
concern.  If your first introduction to your neighbour includes
proposing the removal of the locks on their front door, you have to
understand that they might not consider this a valuable contribution
and might bristle at the idea of handing over responsibility of their
home's security to you.

You are welcome to continue to criticize me and my handling of things,
that's the popular thing to do these days when you disagree with a
maintainer, but I will note that I don't recall you offering to step
up and maintain Lockdown anywhere in this thread.

> Which causes us to carry patches like this downstream.

Which is your choice, and I'm sure you have plenty more patches
unrelated to Lockdown in your downstream repo.

> >> With Clavis, I attempted to develop
> >> an approach that would meet the lockdown threat model requirements
> >> while allowing the end user to control key usage as they deem fit.
> >
> > As mentioned previously, the design/implementation choices you made
> > for Clavis means it is better suited for inclusion in the key
> > subsystem and not as a standalone LSM.  If you wanted to
> > redesign/rework Clavis to stick to the traditional LSM security blobs
> > perhaps that is something we could consider as a LSM, but it's
> > probably worth seeing if David and Jarkko have any interest in
> > including Clavis functionality in the key subsystem first.
>
> The direction of creating a new LSM was based on this discussion ...

Oh so we are going to repeat ourselves, are we?

> A lot of time could have been saved had your concerns been
> voiced in either the first or second round ...

I'm still waiting for someone to connect the dots between a lack of
"timely" review (feel free to define that however you like) and these
never ending threads where we keep rehashing arguments over and over
and over ...

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Mar 21, 2025 at 1:22 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> On Thu, Mar 20, 2025 at 05:36:41PM -0400, Paul Moore wrote:

...

> > I want to address two things, the first, and most important, is that
> > while I am currently employed by Microsoft, I do not speak for
> > Microsoft and the decisions and actions I take as an upstream Linux
> > kernel maintainer are not vetted by Microsoft in any way.  I think you
> > will find that many upstream kernel maintainers operate in a similar
> > way for a variety of very good reasons.
>
> This is understood. If one takes a kernel maintainer role, one should
> unconditionally disobey any vetting by the employer (even at the cost of
> the job, or alternatively at the cost of giving up the maintainership).
>
> And with you in particular I don't think anyone has any trust issues,
> no matter which group of villains you might be employed by ;-)

Haha :D

> > The second issue is that my main focus is on ensuring we have a
> > secure, safe, and well maintained LSM subsystem within the upstream
> > Linux kernel.  While I do care about downstream efforts, e.g. UEFI
> > Secure Boot, those efforts are largely outside the scope of the
> > upstream Linux kernel and not my first concern.  If the developer
> > groups who are focused on things like UEFI SB want to rely on
> > functionality within the upstream Linux kernel they should be prepared
> > to stand up and contribute/maintain those features or else they may go
> > away at some point in the future.  In very blunt terms, contribute
> > upstream or Lockdown dies.
>
> Could Lockdown functionality be re-implemented with that eBPF LSM? I
> have not really looked into it so far...

I haven't looked at it too closely, but the kernel code is very
simplistic so I would be surprised if it couldn't be implemented in
eBPF, although there might be some issues about *very* early boot
(Lockdown can run as an "early" LSM) and integrity which would need to
be addressed (there is work ongoing in that are, see the recent Hornet
posting as one example of that work).  Beyond that there are
policy/political issues around that would need to be worked out;
nothing that couldn't be done, but it would be something that we would
need to sort out.

However, as I mentioned earlier, with Lockdown already present in the
kernel, deprecation and removal is really only an option of last
resort, and I'm hopeful we won't come to that.  We've seen some proper
Lockdown patches submitted overnight (!!!) and I'm discussing
maintainer roles with a couple of people off-list; with a bit of luck
I'm thinking Lockdown might be properly maintained after this upcoming
merge window.  Fingers crossed :)

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 21, 2025, at 10:55 AM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> On Fri, 2025-03-21 at 16:40 +0000, Eric Snowberg wrote:
>>> On Mar 20, 2025, at 4:40 PM, James Bottomley
>>> <James.Bottomley@HansenPartnership.com> wrote:
>>> 
>>> On Thu, 2025-03-20 at 16:24 +0000, Eric Snowberg wrote:
>>>> Having lockdown enforcement has always been 
>>>> a requirement to get a shim signed by Microsoft.
>>> 
>>> This is factually incorrect.  Microsoft transferred shim signing to
>>> an independent process run by a group of open source maintainers a
>>> while ago:
>> 
>> Yes, the shim-review process is understood.  I'm not sure how my
>> sentence  is factually incorrect though.
> 
> You said people "get shim signed by Microsoft".  They don't, they get
> it signed by the key held by the shim-review maintainers.
> 
>> Unless you are saying Microsoft no longer  maintains the private
>> key.
> 
> Well technically the private key is owned by UEFI (and referred to as
> the UEFI CA) but there are multiple HSM based copies floating around
> under the control of various operating system groups.  The Windows OS
> group holds one and the shim-review group holds another ... there are
> probably other copies I don't know about, though.
> 
> The point about this is that UEFI co-ordinates various discussions
> between the private key holders about how to preserve security in the
> UEFI boot environment (mostly at the UEFI Security Sub Team level) it's
> no longer something Microsoft uniquely decides.
> 
>>   Hopefully that is not the case, since the public  key ships on just
>> about every single PC built.
> 
> I don't understand why Microsoft no-longer owning the private key is a
> problem?  Only the public key ships on PCs and that hasn't changed (at
> least not yet, it might have to for NIST requirements since RSA2048 is
> being deprecated).

A couple concerns come to mind.  First, the vetting process being done for 
individuals that have signing authority with the HSM outside of Microsoft.  
Another would be access control of the HSM.  Especially if it is not within
Microsoft's possession.

Re: [RFC PATCH v3 00/13] Clavis LSM

[James Bottomley]

On Fri, 2025-03-21 at 20:15 +0000, Eric Snowberg wrote:
> > On Mar 21, 2025, at 10:55 AM, James Bottomley
> > <James.Bottomley@HansenPartnership.com> wrote:
[...]
> > >   Hopefully that is not the case, since the public  key ships on
> > > just about every single PC built.
> > 
> > I don't understand why Microsoft no-longer owning the private key
> > is a problem?  Only the public key ships on PCs and that hasn't
> > changed (at least not yet, it might have to for NIST requirements
> > since RSA2048 is being deprecated).
> 
> A couple concerns come to mind.  First, the vetting process being
> done for individuals that have signing authority with the HSM outside
> of Microsoft.

I'm not aware UEFI has published any information on this.  I think the
shim-review repo predates UEFI ownership, but I'm sure the maintainers
of the repository can answer how they came to be trusted ...

> Another would be access control of the HSM.  Especially if it is not
> within Microsoft's possession.

... and how they handle the HSM.

However, if you're worried about risks to the integrity of secure boot,
I'd be much more concerned about the number of ODM motherboard
manufacturers who seem to have managed to lose their PK private keys,
or keys they placed into db, somehow ...

Regards,

James

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 21, 2025, at 12:57 PM, Paul Moore <paul@paul-moore.com> wrote:
... 
> , but I will note that I don't recall you offering to step
> up and maintain Lockdown anywhere in this thread.


I didn't realize that trying to contribute a new LSM and being willing to 
be the maintainer of it also involved stepping up to maintain lockdown.

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On Fri, Mar 21, 2025 at 5:21 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > On Mar 21, 2025, at 12:57 PM, Paul Moore <paul@paul-moore.com> wrote:
> ...
> > , but I will note that I don't recall you offering to step
> > up and maintain Lockdown anywhere in this thread.
>
> I didn't realize that trying to contribute a new LSM and being willing to
> be the maintainer of it also involved stepping up to maintain lockdown.

It doesn't, but your criticism of how Lockdown is being handled
definitely falls a bit flat.

-- 
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 21, 2025, at 4:13 PM, Paul Moore <paul@paul-moore.com> wrote:
> 
> On Fri, Mar 21, 2025 at 5:21 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>> On Mar 21, 2025, at 12:57 PM, Paul Moore <paul@paul-moore.com> wrote:
>> ...
>>> , but I will note that I don't recall you offering to step
>>> up and maintain Lockdown anywhere in this thread.
>> 
>> I didn't realize that trying to contribute a new LSM and being willing to
>> be the maintainer of it also involved stepping up to maintain lockdown.
> 
> It doesn't, but your criticism of how Lockdown is being handled
> definitely falls a bit flat.

I merely pointed out the inaccuracy of your assertion that people are freeloading 
off it and not contributing anything substantial by providing an example.

Re: [RFC PATCH v3 00/13] Clavis LSM

[Paul Moore]

On March 21, 2025 6:56:53 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>> On Mar 21, 2025, at 4:13 PM, Paul Moore <paul@paul-moore.com> wrote:
>>
>> On Fri, Mar 21, 2025 at 5:21 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>>>> On Mar 21, 2025, at 12:57 PM, Paul Moore <paul@paul-moore.com> wrote:
>>> ...
>>>> , but I will note that I don't recall you offering to step
>>>> up and maintain Lockdown anywhere in this thread.
>>>
>>> I didn't realize that trying to contribute a new LSM and being willing to
>>> be the maintainer of it also involved stepping up to maintain lockdown.
>>
>> It doesn't, but your criticism of how Lockdown is being handled
>> definitely falls a bit flat.
>
> I merely pointed out the inaccuracy of your assertion that people are 
> freeloading
> off it and not contributing anything substantial by providing an example.

In my opinion the example you provided did not demonstrate that at all for 
reasons already mentioned.  As for the issue of freeloading on Lockdown, I 
believe I've already made myself clear on that point.

--
paul-moore.com

Re: [RFC PATCH v3 00/13] Clavis LSM

[Eric Snowberg]

> On Mar 21, 2025, at 2:53 PM, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> On Fri, 2025-03-21 at 20:15 +0000, Eric Snowberg wrote:
>>> On Mar 21, 2025, at 10:55 AM, James Bottomley
>>> <James.Bottomley@HansenPartnership.com> wrote:
> [...]
>>>>   Hopefully that is not the case, since the public  key ships on
>>>> just about every single PC built.
>>> 
>>> I don't understand why Microsoft no-longer owning the private key
>>> is a problem?  Only the public key ships on PCs and that hasn't
>>> changed (at least not yet, it might have to for NIST requirements
>>> since RSA2048 is being deprecated).
>> 
>> A couple concerns come to mind.  First, the vetting process being
>> done for individuals that have signing authority with the HSM outside
>> of Microsoft.
> 
> I'm not aware UEFI has published any information on this.  I think the
> shim-review repo predates UEFI ownership, but I'm sure the maintainers
> of the repository can answer how they came to be trusted ...

Thanks for clarifying, I didn’t realize there were copies of the private key 
outside of Microsoft.

>> Another would be access control of the HSM.  Especially if it is not
>> within Microsoft's possession.
> 
> ... and how they handle the HSM.
> 
> However, if you're worried about risks to the integrity of secure boot,
> I'd be much more concerned about the number of ODM motherboard
> manufacturers who seem to have managed to lose their PK private keys,
> or keys they placed into db, somehow ...

That’s precisely the protection Clavis offers. It begins immediately after 
ExitBootServices and continues through all kexecs. Once the kernel starts, 
the end-user is in control of all system kernel keys.  Obviously some type 
of precaution must be taken to get into the first kernel.  The Clavis key 
belongs to the end-user, and they have the freedom to determine which 
kernel keys perform specific tasks within the system. This level of protection 
wouldn’t be feasible with the proposed named kernel keyring approach.  
With the named kernel keyring approach, it could be defeated with kexec.
When you have hardware vendors shipping systems in the past with test/demo 
DB/KEK/PK keys, or other companies that allow their signing key to be used 
by others, this level of protection is sought after by some users.