LinuxLists.cc - [PATCH v10 0/8] Enroll kernel keys thru MOK

[permalink] [raw]

Subject: [PATCH v10 4/8] KEYS: store reference to machine keyring

Expose the .machine keyring created in integrity code by adding
a reference. Store a reference to the machine keyring in
system keyring code. The system keyring code needs this to complete
the keyring link to the machine keyring.

Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
---
v2: Initial version
v3: Unmodified from v2
v4: Removed trust_moklist check
v5: Rename to machine keyring
v8: Unmodified from v5
v9: Combine with "add reference to machine keyring" patch
v10: Added Jarkko's Reviewed-by and Mimi's Tested-by
---
certs/system_keyring.c | 9 +++++++++
include/keys/system_keyring.h | 8 ++++++++
security/integrity/digsig.c | 2 ++
3 files changed, 19 insertions(+)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 692365dee2bd..08ea542c8096 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -22,6 +22,9 @@ static struct key *builtin_trusted_keys;
#ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
static struct key *secondary_trusted_keys;
#endif
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+static struct key *machine_trusted_keys;
+#endif
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
static struct key *platform_trusted_keys;
#endif
@@ -91,6 +94,12 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
return restriction;
}
#endif
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+void __init set_machine_trusted_keys(struct key *keyring)
+{
+ machine_trusted_keys = keyring;
+}
+#endif

/*
* Create the trusted keyrings
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 6acd3cf13a18..98c9b10cdc17 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -38,6 +38,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
#define restrict_link_by_builtin_and_secondary_trusted restrict_link_by_builtin_trusted
#endif

+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+extern void __init set_machine_trusted_keys(struct key *keyring);
+#else
+static inline void __init set_machine_trusted_keys(struct key *keyring)
+{
+}
+#endif
+
extern struct pkcs7_message *pkcs7;
#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
extern int mark_hash_blacklisted(const char *hash);
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 2b7fa85613c0..7b719aa76188 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -112,6 +112,8 @@ static int __init __integrity_init_keyring(const unsigned int id,
} else {
if (id == INTEGRITY_KEYRING_PLATFORM)
set_platform_trusted_keys(keyring[id]);
+ if (id == INTEGRITY_KEYRING_MACHINE)
+ set_machine_trusted_keys(keyring[id]);
if (id == INTEGRITY_KEYRING_IMA)
load_module_cert(keyring[id]);
}
--
2.18.4

2022-01-26 16:21:23

[permalink] [raw]

Subject: [PATCH v10 1/8] integrity: Fix warning about missing prototypes

make W=1 generates the following warning in keyring_handler.c

security/integrity/platform_certs/keyring_handler.c:71:30: warning: no previous prototype for get_handler_for_db [-Wmissing-prototypes]
__init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
^~~~~~~~~~~~~~~~~~
security/integrity/platform_certs/keyring_handler.c:82:30: warning: no previous prototype for get_handler_for_dbx [-Wmissing-prototypes]
__init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type)
^~~~~~~~~~~~~~~~~~~
Add the missing prototypes by including keyring_handler.h.

Reported-by: kernel test robot <[email protected]>
Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
---
v7: Initial version
v8: Code unmodified from v7 added Mimi's Reviewed-by
v9: Unmodified from v8
v10: Added Jarkko's Reviewed-by and Mimi's Tested-by
---
security/integrity/platform_certs/keyring_handler.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index 5604bd57c990..e9791be98fd9 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -9,6 +9,7 @@
#include <keys/asymmetric-type.h>
#include <keys/system_keyring.h>
#include "../integrity.h"
+#include "keyring_handler.h"

static efi_guid_t efi_cert_x509_guid __initdata = EFI_CERT_X509_GUID;
static efi_guid_t efi_cert_x509_sha256_guid __initdata =
--
2.18.4

2022-01-26 16:21:58

[permalink] [raw]

Subject: [PATCH v10 7/8] integrity: Trust MOK keys if MokListTrustedRT found

A new Machine Owner Key (MOK) variable called MokListTrustedRT has been
introduced in shim. When this UEFI variable is set, it indicates the
end-user has made the decision themselves that they wish to trust MOK keys
within the Linux trust boundary. It is not an error if this variable
does not exist. If it does not exist, the MOK keys should not be trusted
within the kernel.

Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
---
v1: Initial version
v2: Removed mok_keyring_trust_setup function
v4: Unmodified from v2
v5: Rename to machine keyring
v6: Unmodified from v5
v7: Use mokvar table instead of EFI var (suggested by Peter Jones)
v9: Unmodified from v7
v10: Added Jarkko's Reviewed-by
---
.../platform_certs/machine_keyring.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/security/integrity/platform_certs/machine_keyring.c b/security/integrity/platform_certs/machine_keyring.c
index ea2ac2f9f2b5..09fd8f20c756 100644
--- a/security/integrity/platform_certs/machine_keyring.c
+++ b/security/integrity/platform_certs/machine_keyring.c
@@ -5,6 +5,7 @@
* Copyright (c) 2021, Oracle and/or its affiliates.
*/

+#include <linux/efi.h>
#include "../integrity.h"

static __init int machine_keyring_init(void)
@@ -40,3 +41,21 @@ void __init add_to_machine_keyring(const char *source, const void *data, size_t
if (rc)
pr_info("Error adding keys to machine keyring %s\n", source);
}
+
+/*
+ * Try to load the MokListTrustedRT MOK variable to see if we should trust
+ * the MOK keys within the kernel. It is not an error if this variable
+ * does not exist. If it does not exist, MOK keys should not be trusted
+ * within the machine keyring.
+ */
+static __init bool uefi_check_trust_mok_keys(void)
+{
+ struct efi_mokvar_table_entry *mokvar_entry;
+
+ mokvar_entry = efi_mokvar_entry_find("MokListTrustedRT");
+
+ if (mokvar_entry)
+ return true;
+
+ return false;
+}
--
2.18.4

2022-01-26 16:22:13

[permalink] [raw]

Subject: [PATCH v10 5/8] KEYS: Introduce link restriction for machine keys

Introduce a new link restriction that includes the trusted builtin,
secondary and machine keys. The restriction is based on the key to be
added being vouched for by a key in any of these three keyrings.

With the introduction of the machine keyring, the end-user may choose to
trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
trust them, the .machine keyring will contain these keys. If not, the
machine keyring will always be empty. Update the restriction check to
allow the secondary trusted keyring to also trust machine keys.

Allow the .machine keyring to be linked to the secondary_trusted_keys.
After the link is created, keys contained in the .machine keyring will
automatically be searched when searching secondary_trusted_keys.

Suggested-by: Mimi Zohar <[email protected]>
Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
---
v3: Initial version
v4: moved code under CONFIG_INTEGRITY_MOK_KEYRING
v5: Rename to machine keyring
v6: Change subject name (suggested by Mimi)
Rename restrict_link_by_builtin_secondary_and_ca_trusted
to restrict_link_by_builtin_secondary_and_machine (suggested by
Mimi)
v7: Unmodified from v6
v8: Add missing parameter definitions (suggested by Mimi)
v9: Combine with "change link restriction to trust the machine keyring"
patch
v10: Add Jarkko's Reviewed-by and Mimi's Tested-by, also removed ima
reference above.
---
certs/system_keyring.c | 35 ++++++++++++++++++++++++++++++++++-
include/keys/system_keyring.h | 6 ++++++
2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 08ea542c8096..05b66ce9d1c9 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -89,7 +89,10 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
if (!restriction)
panic("Can't allocate secondary trusted keyring restriction\n");

- restriction->check = restrict_link_by_builtin_and_secondary_trusted;
+ if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
+ restriction->check = restrict_link_by_builtin_secondary_and_machine;
+ else
+ restriction->check = restrict_link_by_builtin_and_secondary_trusted;

return restriction;
}
@@ -98,6 +101,36 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
void __init set_machine_trusted_keys(struct key *keyring)
{
machine_trusted_keys = keyring;
+
+ if (key_link(secondary_trusted_keys, machine_trusted_keys) < 0)
+ panic("Can't link (machine) trusted keyrings\n");
+}
+
+/**
+ * restrict_link_by_builtin_secondary_and_machine - Restrict keyring addition.
+ * @dest_keyring: Keyring being linked to.
+ * @type: The type of key being added.
+ * @payload: The payload of the new key.
+ * @restrict_key: A ring of keys that can be used to vouch for the new cert.
+ *
+ * Restrict the addition of keys into a keyring based on the key-to-be-added
+ * being vouched for by a key in either the built-in, the secondary, or
+ * the machine keyrings.
+ */
+int restrict_link_by_builtin_secondary_and_machine(
+ struct key *dest_keyring,
+ const struct key_type *type,
+ const union key_payload *payload,
+ struct key *restrict_key)
+{
+ if (machine_trusted_keys && type == &key_type_keyring &&
+ dest_keyring == secondary_trusted_keys &&
+ payload == &machine_trusted_keys->payload)
+ /* Allow the machine keyring to be added to the secondary */
+ return 0;
+
+ return restrict_link_by_builtin_and_secondary_trusted(dest_keyring, type,
+ payload, restrict_key);
}
#endif

diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 98c9b10cdc17..2419a735420f 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -39,8 +39,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
#endif

#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+extern int restrict_link_by_builtin_secondary_and_machine(
+ struct key *dest_keyring,
+ const struct key_type *type,
+ const union key_payload *payload,
+ struct key *restrict_key);
extern void __init set_machine_trusted_keys(struct key *keyring);
#else
+#define restrict_link_by_builtin_secondary_and_machine restrict_link_by_builtin_trusted
static inline void __init set_machine_trusted_keys(struct key *keyring)
{
}
--
2.18.4

2022-01-26 16:22:49

[permalink] [raw]

Subject: [PATCH v10 2/8] integrity: Introduce a Linux keyring called machine

Many UEFI Linux distributions boot using shim. The UEFI shim provides
what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure
Boot DB and MOK keys to validate the next step in the boot chain. The
MOK facility can be used to import user generated keys. These keys can
be used to sign an end-users development kernel build. When Linux
boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux
.platform keyring.

Define a new Linux keyring called machine. This keyring shall contain just
MOK keys and not the remaining keys in the platform keyring. This new
machine keyring will be used in follow on patches. Unlike keys in the
platform keyring, keys contained in the machine keyring will be trusted
within the kernel if the end-user has chosen to do so.

Signed-off-by: Eric Snowberg <[email protected]>
Tested-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
---
v1: Initial version
v2: Removed destory keyring code
v3: Unmodified from v2
v4: Add Kconfig, merged in "integrity: add add_to_mok_keyring"
v5: Rename to machine keyring
v6: Depend on EFI in kconfig (suggested by Mimi)
Test to see if ".platform" keyring is configured in
add_to_machine_keyring (suggested by Mimi)
v7: Depend on LOAD_UEFI_KEYS instead EFI for mokvar code
v8: Code unmodified from v7 added Mimi's Reviewed-by
v9: Removed Reviewed-by. Prevent IMA from being able to
use the machine keyring since the CA restrictions
v10: Added Jarkko and Mimi's Tested-by, removed CA references.
---
security/integrity/Kconfig | 13 ++++++
security/integrity/Makefile | 1 +
security/integrity/digsig.c | 13 +++++-
security/integrity/integrity.h | 12 +++++-
.../platform_certs/machine_keyring.c | 42 +++++++++++++++++++
5 files changed, 78 insertions(+), 3 deletions(-)
create mode 100644 security/integrity/platform_certs/machine_keyring.c

diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index 71f0177e8716..de02964dd421 100644
--- a/security/integrity/Kconfig
+++ b/security/integrity/Kconfig
@@ -62,6 +62,19 @@ config INTEGRITY_PLATFORM_KEYRING
provided by the platform for verifying the kexec'ed kerned image
and, possibly, the initramfs signature.

+config INTEGRITY_MACHINE_KEYRING
+ bool "Provide a keyring to which Machine Owner Keys may be added"
+ depends on SECONDARY_TRUSTED_KEYRING
+ depends on INTEGRITY_ASYMMETRIC_KEYS
+ depends on SYSTEM_BLACKLIST_KEYRING
+ depends on LOAD_UEFI_KEYS
+ depends on !IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
+ help
+ If set, provide a keyring to which Machine Owner Keys (MOK) may
+ be added. This keyring shall contain just MOK keys. Unlike keys
+ in the platform keyring, keys contained in the .machine keyring will
+ be trusted within the kernel.
+
config LOAD_UEFI_KEYS
depends on INTEGRITY_PLATFORM_KEYRING
depends on EFI
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 7ee39d66cf16..d0ffe37dc1d6 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -10,6 +10,7 @@ integrity-$(CONFIG_INTEGRITY_AUDIT) += integrity_audit.o
integrity-$(CONFIG_INTEGRITY_SIGNATURE) += digsig.o
integrity-$(CONFIG_INTEGRITY_ASYMMETRIC_KEYS) += digsig_asymmetric.o
integrity-$(CONFIG_INTEGRITY_PLATFORM_KEYRING) += platform_certs/platform_keyring.o
+integrity-$(CONFIG_INTEGRITY_MACHINE_KEYRING) += platform_certs/machine_keyring.o
integrity-$(CONFIG_LOAD_UEFI_KEYS) += platform_certs/efi_parser.o \
platform_certs/load_uefi.o \
platform_certs/keyring_handler.o
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 3b06a01bd0fd..2b7fa85613c0 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -30,6 +30,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
".ima",
#endif
".platform",
+ ".machine",
};

#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
@@ -126,7 +127,8 @@ int __init integrity_init_keyring(const unsigned int id)
perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW
| KEY_USR_READ | KEY_USR_SEARCH;

- if (id == INTEGRITY_KEYRING_PLATFORM) {
+ if (id == INTEGRITY_KEYRING_PLATFORM ||
+ id == INTEGRITY_KEYRING_MACHINE) {
restriction = NULL;
goto out;
}
@@ -139,7 +141,14 @@ int __init integrity_init_keyring(const unsigned int id)
return -ENOMEM;

restriction->check = restrict_link_to_ima;
- perm |= KEY_USR_WRITE;
+
+ /*
+ * MOK keys can only be added through a read-only runtime services
+ * UEFI variable during boot. No additional keys shall be allowed to
+ * load into the machine keyring following init from userspace.
+ */
+ if (id != INTEGRITY_KEYRING_MACHINE)
+ perm |= KEY_USR_WRITE;

out:
return __integrity_init_keyring(id, perm, restriction);
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 547425c20e11..730771eececd 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -151,7 +151,8 @@ int integrity_kernel_read(struct file *file, loff_t offset,
#define INTEGRITY_KEYRING_EVM 0
#define INTEGRITY_KEYRING_IMA 1
#define INTEGRITY_KEYRING_PLATFORM 2
-#define INTEGRITY_KEYRING_MAX 3
+#define INTEGRITY_KEYRING_MACHINE 3
+#define INTEGRITY_KEYRING_MAX 4

extern struct dentry *integrity_dir;

@@ -283,3 +284,12 @@ static inline void __init add_to_platform_keyring(const char *source,
{
}
#endif
+
+#ifdef CONFIG_INTEGRITY_MACHINE_KEYRING
+void __init add_to_machine_keyring(const char *source, const void *data, size_t len);
+#else
+static inline void __init add_to_machine_keyring(const char *source,
+ const void *data, size_t len)
+{
+}
+#endif
diff --git a/security/integrity/platform_certs/machine_keyring.c b/security/integrity/platform_certs/machine_keyring.c
new file mode 100644
index 000000000000..ea2ac2f9f2b5
--- /dev/null
+++ b/security/integrity/platform_certs/machine_keyring.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Machine keyring routines.
+ *
+ * Copyright (c) 2021, Oracle and/or its affiliates.
+ */
+
+#include "../integrity.h"
+
+static __init int machine_keyring_init(void)
+{
+ int rc;
+
+ rc = integrity_init_keyring(INTEGRITY_KEYRING_MACHINE);
+ if (rc)
+ return rc;
+
+ pr_notice("Machine keyring initialized\n");
+ return 0;
+}
+device_initcall(machine_keyring_init);
+
+void __init add_to_machine_keyring(const char *source, const void *data, size_t len)
+{
+ key_perm_t perm;
+ int rc;
+
+ perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW;
+ rc = integrity_load_cert(INTEGRITY_KEYRING_MACHINE, source, data, len, perm);
+
+ /*
+ * Some MOKList keys may not pass the machine keyring restrictions.
+ * If the restriction check does not pass and the platform keyring
+ * is configured, try to add it into that keyring instead.
+ */
+ if (rc && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
+ rc = integrity_load_cert(INTEGRITY_KEYRING_PLATFORM, source,
+ data, len, perm);
+
+ if (rc)
+ pr_info("Error adding keys to machine keyring %s\n", source);
+}
--
2.18.4

2022-01-26 16:23:16

[permalink] [raw]

Subject: [PATCH v10 3/8] integrity: add new keyring handler for mok keys

Currently both Secure Boot DB and Machine Owner Keys (MOK) go through
the same keyring handler (get_handler_for_db). With the addition of the
new machine keyring, the end-user may choose to trust MOK keys.

Introduce a new keyring handler specific for MOK keys. If MOK keys are
trusted by the end-user, use the new keyring handler instead.

Signed-off-by: Eric Snowberg <[email protected]>
Reviewed-by: Mimi Zohar <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Mimi Zohar <[email protected]>
---
v1: Initial version
v3: Only change the keyring handler if the secondary is enabled
v4: Removed trust_moklist check
v5: Rename to machine keyring
v7: Unmodified from v5
v8: Code unmodified from v7 added Mimi's Reviewed-by
v9: Unmodified from v8
v10: Added Jarkko's Reviewed-by and Mimi's Tested-by
---
.../integrity/platform_certs/keyring_handler.c | 17 ++++++++++++++++-
.../integrity/platform_certs/keyring_handler.h | 5 +++++
security/integrity/platform_certs/load_uefi.c | 4 ++--
3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index e9791be98fd9..4872850d081f 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -67,7 +67,7 @@ static __init void uefi_revocation_list_x509(const char *source,

/*
* Return the appropriate handler for particular signature list types found in
- * the UEFI db and MokListRT tables.
+ * the UEFI db tables.
*/
__init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
{
@@ -76,6 +76,21 @@ __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type)
return 0;
}

+/*
+ * Return the appropriate handler for particular signature list types found in
+ * the MokListRT tables.
+ */
+__init efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type)
+{
+ if (efi_guidcmp(*sig_type, efi_cert_x509_guid) == 0) {
+ if (IS_ENABLED(CONFIG_INTEGRITY_MACHINE_KEYRING))
+ return add_to_machine_keyring;
+ else
+ return add_to_platform_keyring;
+ }
+ return 0;
+}
+
/*
* Return the appropriate handler for particular signature list types found in
* the UEFI dbx and MokListXRT tables.
diff --git a/security/integrity/platform_certs/keyring_handler.h b/security/integrity/platform_certs/keyring_handler.h
index 2462bfa08fe3..284558f30411 100644
--- a/security/integrity/platform_certs/keyring_handler.h
+++ b/security/integrity/platform_certs/keyring_handler.h
@@ -24,6 +24,11 @@ void blacklist_binary(const char *source, const void *data, size_t len);
*/
efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type);

+/*
+ * Return the handler for particular signature list types found in the mok.
+ */
+efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type);
+
/*
* Return the handler for particular signature list types found in the dbx.
*/
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index 08b6d12f99b4..5f45c3c07dbd 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -95,7 +95,7 @@ static int __init load_moklist_certs(void)
rc = parse_efi_signature_list("UEFI:MokListRT (MOKvar table)",
mokvar_entry->data,
mokvar_entry->data_size,
- get_handler_for_db);
+ get_handler_for_mok);
/* All done if that worked. */
if (!rc)
return rc;
@@ -110,7 +110,7 @@ static int __init load_moklist_certs(void)
mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status);
if (mok) {
rc = parse_efi_signature_list("UEFI:MokListRT",
- mok, moksize, get_handler_for_db);
+ mok, moksize, get_handler_for_mok);
kfree(mok);
if (rc)
pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
--
2.18.4

2022-01-26 21:24:00

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Tue, Jan 25, 2022 at 09:58:26PM -0500, Eric Snowberg wrote:
> Back in 2013 Linus requested a feature to allow end-users to have the
> ability "to add their own keys and sign modules they trust". This was
> his *second* order outlined here [1]. There have been many attempts
> over the years to solve this problem, all have been rejected. Many
> of the failed attempts loaded all preboot firmware keys into the kernel,
> including the Secure Boot keys. Many distributions carry one of these
> rejected attempts [2], [3], [4]. This series tries to solve this problem
> with a solution that takes into account all the problems brought up in
> the previous attempts.
>
> On UEFI based systems, this series introduces a new Linux kernel keyring
> containing the Machine Owner Keys (MOK) called machine. It also defines
> a new MOK variable in shim. This variable allows the end-user to decide
> if they want to load MOK keys into the machine keyring.
>
> By default, nothing changes; MOK keys are not loaded into the machine
> keyring. They are only loaded after the end-user makes the decision
> themselves. The end-user would set this through mokutil using a new
> --trust-mok option [5]. This would work similar to how the kernel uses
> MOK variables to enable/disable signature validation as well as use/ignore
> the db. Any kernel operation that uses either the builtin or secondary
> trusted keys as a trust source shall also reference the new machine
> keyring as a trust source.
>
> Secure Boot keys will never be loaded into the machine keyring. They
> will always be loaded into the platform keyring. If an end-user wanted
> to load one, they would need to enroll it into the MOK.
>
> Unlike previous versions of this patch set, IMA support has been removed
> to simplify the series. After acceptance, a follow-on series will add IMA
> support.
>
> Steps required by the end user:
>
> Sign kernel module with user created key:
> $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
> machine_signing_key.priv machine_signing_key.x509 my_module.ko
>
> Import the key into the MOK
> $ mokutil --import machine_signing_key.x509
>
> Setup the kernel to load MOK keys into the .machine keyring
> $ mokutil --trust-mok
>
> Then reboot, the MokManager will load and ask if you want to trust the
> MOK key and enroll the MOK into the MOKList. Afterwards the signed kernel
> module will load.
>
> I have included a link to the mokutil [5] changes I have made to support
> this new functionality. The shim changes have now been accepted
> upstream [6].
>
> Upstream shim is located here [7], the build instructions are here [8].
> TLDR:
>
> $ git clone --recurse-submodules https://github.com/rhboot/shim
> $ cd shim
> $ make
>
> After building shim, move shimx64.efi and mmx64.efi to the vendor or
> distribution specific directory on your EFI System Partition (assuming
> you are building on x86). The instructions above are the minimal
> steps needed to build shim to test this feature. It is assumed
> Secure Boot shall not be enabled for this testing. To do testing
> with Secure Boot enabled, all steps in the build instructions [8]
> must be followed.
>
> Instructions for building mokutil (including the new changes):
>
> $ git clone -b mokvars-v3 https://github.com/esnowberg/mokutil.git
> $ cd mokutil/
> $ ./autogen.sh
> $ make
>
> [1] https://marc.info/?l=linux-kernel&m=136185386310140&w=2
> [2] https://lore.kernel.org/lkml/[email protected]/
> [3] https://lore.kernel.org/lkml/[email protected]/
> [4] https://lore.kernel.org/linux-integrity/1e41f22b1f11784f1e943f32bf62034d4e054cdb.camel@HansenPartnership.com/
> [5] https://github.com/esnowberg/mokutil/tree/mokvars-v3
> [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> [7] https://github.com/rhboot/shim
> [8] https://github.com/rhboot/shim/blob/main/BUILDING
>
> Eric Snowberg (8):
> integrity: Fix warning about missing prototypes
> integrity: Introduce a Linux keyring called machine
> integrity: add new keyring handler for mok keys
> KEYS: store reference to machine keyring
> KEYS: Introduce link restriction for machine keys
> efi/mokvar: move up init order
> integrity: Trust MOK keys if MokListTrustedRT found
> integrity: Only use machine keyring when uefi_check_trust_mok_keys is
> true
>
> certs/system_keyring.c | 44 ++++++++++-
> drivers/firmware/efi/mokvar-table.c | 2 +-
> include/keys/system_keyring.h | 14 ++++
> security/integrity/Kconfig | 13 ++++
> security/integrity/Makefile | 1 +
> security/integrity/digsig.c | 15 +++-
> security/integrity/integrity.h | 17 +++-
> .../platform_certs/keyring_handler.c | 18 ++++-
> .../platform_certs/keyring_handler.h | 5 ++
> security/integrity/platform_certs/load_uefi.c | 4 +-
> .../platform_certs/machine_keyring.c | 77 +++++++++++++++++++
> 11 files changed, 202 insertions(+), 8 deletions(-)
> create mode 100644 security/integrity/platform_certs/machine_keyring.c
>
>
> base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
> --
> 2.18.4
>

Thank you. I'll pick these soon. Is there any objections?

/Jarkko

2022-01-26 21:27:45

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Wed, Jan 26, 2022 at 03:43:07PM +0200, Jarkko Sakkinen wrote:
> On Tue, Jan 25, 2022 at 09:58:26PM -0500, Eric Snowberg wrote:
> > Back in 2013 Linus requested a feature to allow end-users to have the
> > ability "to add their own keys and sign modules they trust". This was
> > his *second* order outlined here [1]. There have been many attempts
> > over the years to solve this problem, all have been rejected. Many
> > of the failed attempts loaded all preboot firmware keys into the kernel,
> > including the Secure Boot keys. Many distributions carry one of these
> > rejected attempts [2], [3], [4]. This series tries to solve this problem
> > with a solution that takes into account all the problems brought up in
> > the previous attempts.
> >
> > On UEFI based systems, this series introduces a new Linux kernel keyring
> > containing the Machine Owner Keys (MOK) called machine. It also defines
> > a new MOK variable in shim. This variable allows the end-user to decide
> > if they want to load MOK keys into the machine keyring.
> >
> > By default, nothing changes; MOK keys are not loaded into the machine
> > keyring. They are only loaded after the end-user makes the decision
> > themselves. The end-user would set this through mokutil using a new
> > --trust-mok option [5]. This would work similar to how the kernel uses
> > MOK variables to enable/disable signature validation as well as use/ignore
> > the db. Any kernel operation that uses either the builtin or secondary
> > trusted keys as a trust source shall also reference the new machine
> > keyring as a trust source.
> >
> > Secure Boot keys will never be loaded into the machine keyring. They
> > will always be loaded into the platform keyring. If an end-user wanted
> > to load one, they would need to enroll it into the MOK.
> >
> > Unlike previous versions of this patch set, IMA support has been removed
> > to simplify the series. After acceptance, a follow-on series will add IMA
> > support.
> >
> > Steps required by the end user:
> >
> > Sign kernel module with user created key:
> > $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \
> > machine_signing_key.priv machine_signing_key.x509 my_module.ko
> >
> > Import the key into the MOK
> > $ mokutil --import machine_signing_key.x509
> >
> > Setup the kernel to load MOK keys into the .machine keyring
> > $ mokutil --trust-mok
> >
> > Then reboot, the MokManager will load and ask if you want to trust the
> > MOK key and enroll the MOK into the MOKList. Afterwards the signed kernel
> > module will load.
> >
> > I have included a link to the mokutil [5] changes I have made to support
> > this new functionality. The shim changes have now been accepted
> > upstream [6].
> >
> > Upstream shim is located here [7], the build instructions are here [8].
> > TLDR:
> >
> > $ git clone --recurse-submodules https://github.com/rhboot/shim
> > $ cd shim
> > $ make
> >
> > After building shim, move shimx64.efi and mmx64.efi to the vendor or
> > distribution specific directory on your EFI System Partition (assuming
> > you are building on x86). The instructions above are the minimal
> > steps needed to build shim to test this feature. It is assumed
> > Secure Boot shall not be enabled for this testing. To do testing
> > with Secure Boot enabled, all steps in the build instructions [8]
> > must be followed.
> >
> > Instructions for building mokutil (including the new changes):
> >
> > $ git clone -b mokvars-v3 https://github.com/esnowberg/mokutil.git
> > $ cd mokutil/
> > $ ./autogen.sh
> > $ make
> >
> > [1] https://marc.info/?l=linux-kernel&m=136185386310140&w=2
> > [2] https://lore.kernel.org/lkml/[email protected]/
> > [3] https://lore.kernel.org/lkml/[email protected]/
> > [4] https://lore.kernel.org/linux-integrity/1e41f22b1f11784f1e943f32bf62034d4e054cdb.camel@HansenPartnership.com/
> > [5] https://github.com/esnowberg/mokutil/tree/mokvars-v3
> > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f
> > [7] https://github.com/rhboot/shim
> > [8] https://github.com/rhboot/shim/blob/main/BUILDING
> >
> > Eric Snowberg (8):
> > integrity: Fix warning about missing prototypes
> > integrity: Introduce a Linux keyring called machine
> > integrity: add new keyring handler for mok keys
> > KEYS: store reference to machine keyring
> > KEYS: Introduce link restriction for machine keys
> > efi/mokvar: move up init order
> > integrity: Trust MOK keys if MokListTrustedRT found
> > integrity: Only use machine keyring when uefi_check_trust_mok_keys is
> > true
> >
> > certs/system_keyring.c | 44 ++++++++++-
> > drivers/firmware/efi/mokvar-table.c | 2 +-
> > include/keys/system_keyring.h | 14 ++++
> > security/integrity/Kconfig | 13 ++++
> > security/integrity/Makefile | 1 +
> > security/integrity/digsig.c | 15 +++-
> > security/integrity/integrity.h | 17 +++-
> > .../platform_certs/keyring_handler.c | 18 ++++-
> > .../platform_certs/keyring_handler.h | 5 ++
> > security/integrity/platform_certs/load_uefi.c | 4 +-
> > .../platform_certs/machine_keyring.c | 77 +++++++++++++++++++
> > 11 files changed, 202 insertions(+), 8 deletions(-)
> > create mode 100644 security/integrity/platform_certs/machine_keyring.c
> >
> >
> > base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07
> > --
> > 2.18.4
> >
>
> Thank you. I'll pick these soon. Is there any objections?

Mimi brought up that we need a MAINTAINERS update for this and also
.platform.

We have these:

- KEYS/KEYRINGS
- CERTIFICATE HANDLING

I would put them under KEYRINGS for now and would not consider further
subdivision for the moment.

/Jarkko

2022-01-27 02:04:48

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

Hi Jarkko,

> > Thank you. I'll pick these soon. Is there any objections?

No objections.
>
> Mimi brought up that we need a MAINTAINERS update for this and also
> .platform.
>
> We have these:
>
> - KEYS/KEYRINGS
> - CERTIFICATE HANDLING
>
> I would put them under KEYRINGS for now and would not consider further
> subdivision for the moment.

IMA has dependencies on the platform_certs/ and now on the new .machine
keyring. Just adding "F: security/integrity/platform_certs/" to the
KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
even be on the linux-integrity mailing list.

Existing requirement:
- The keys on the .platform keyring are limited to verifying the kexec
image.

New requirements based on Eric Snowbergs' patch set:
- When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
the MOK keys will not be loaded directly onto the .machine keyring or
indirectly onto the .secondary_trusted_keys keyring.

- Only when a new IMA Kconfig explicitly allows the keys on the
.machine keyrings, will the CA keys stored in MOK be loaded onto the
.machine keyring.

Unfortunately I don't think there is any choice, but to define a new
MAINTAINERS entry. Perhaps something along the lines of:

KEYS/KEYRINGS_INTEGRITY
M: Jarkko Sakkinen <[email protected]>
M: Mimi Zohar <[email protected]>
L: [email protected]
L: [email protected]
F: security/integrity/platform_certs

thanks,

Mimi

2022-02-09 12:05:23

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:
> Hi Jarkko,
>
> > > Thank you. I'll pick these soon. Is there any objections?
>
> No objections.
> >
> > Mimi brought up that we need a MAINTAINERS update for this and also
> > .platform.
> >
> > We have these:
> >
> > - KEYS/KEYRINGS
> > - CERTIFICATE HANDLING
> >
> > I would put them under KEYRINGS for now and would not consider further
> > subdivision for the moment.
>
> IMA has dependencies on the platform_certs/ and now on the new .machine
> keyring. Just adding "F: security/integrity/platform_certs/" to the
> KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
> even be on the linux-integrity mailing list.
>
> Existing requirement:
> - The keys on the .platform keyring are limited to verifying the kexec
> image.
>
> New requirements based on Eric Snowbergs' patch set:
> - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
> the MOK keys will not be loaded directly onto the .machine keyring or
> indirectly onto the .secondary_trusted_keys keyring.
>
> - Only when a new IMA Kconfig explicitly allows the keys on the
> .machine keyrings, will the CA keys stored in MOK be loaded onto the
> .machine keyring.
>
> Unfortunately I don't think there is any choice, but to define a new
> MAINTAINERS entry. Perhaps something along the lines of:
>
> KEYS/KEYRINGS_INTEGRITY
> M: Jarkko Sakkinen <[email protected]>
> M: Mimi Zohar <[email protected]>
> L: [email protected]
> L: [email protected]
> F: security/integrity/platform_certs

WFM. BTW, the patches are now in my tree:

git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git

I can add any tags requested. I'll mirror this at some point to linux-next.

/Jarkko

2022-02-20 23:46:13

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:
> Hi Jarkko,
>
> > > Thank you. I'll pick these soon. Is there any objections?
>
> No objections.
> >
> > Mimi brought up that we need a MAINTAINERS update for this and also
> > .platform.
> >
> > We have these:
> >
> > - KEYS/KEYRINGS
> > - CERTIFICATE HANDLING
> >
> > I would put them under KEYRINGS for now and would not consider further
> > subdivision for the moment.
>
> IMA has dependencies on the platform_certs/ and now on the new .machine
> keyring. Just adding "F: security/integrity/platform_certs/" to the
> KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
> even be on the linux-integrity mailing list.
>
> Existing requirement:
> - The keys on the .platform keyring are limited to verifying the kexec
> image.
>
> New requirements based on Eric Snowbergs' patch set:
> - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
> the MOK keys will not be loaded directly onto the .machine keyring or
> indirectly onto the .secondary_trusted_keys keyring.
>
> - Only when a new IMA Kconfig explicitly allows the keys on the
> .machine keyrings, will the CA keys stored in MOK be loaded onto the
> .machine keyring.
>
> Unfortunately I don't think there is any choice, but to define a new
> MAINTAINERS entry. Perhaps something along the lines of:
>
> KEYS/KEYRINGS_INTEGRITY
> M: Jarkko Sakkinen <[email protected]>
> M: Mimi Zohar <[email protected]>
> L: [email protected]
> L: [email protected]
> F: security/integrity/platform_certs
>
> thanks,
>
> Mimi

This would work for me.

BR, Jarkko

2022-02-22 12:25:06

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Sun, 2022-02-20 at 20:00 +0100, Jarkko Sakkinen wrote:
> On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:

> > >
> > > Mimi brought up that we need a MAINTAINERS update for this and also
> > > .platform.
> > >
> > > We have these:
> > >
> > > - KEYS/KEYRINGS
> > > - CERTIFICATE HANDLING
> > >
> > > I would put them under KEYRINGS for now and would not consider further
> > > subdivision for the moment.
> >
> > IMA has dependencies on the platform_certs/ and now on the new .machine
> > keyring. Just adding "F: security/integrity/platform_certs/" to the
> > KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
> > even be on the linux-integrity mailing list.
> >
> > Existing requirement:
> > - The keys on the .platform keyring are limited to verifying the kexec
> > image.
> >
> > New requirements based on Eric Snowbergs' patch set:
> > - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
> > the MOK keys will not be loaded directly onto the .machine keyring or
> > indirectly onto the .secondary_trusted_keys keyring.
> >
> > - Only when a new IMA Kconfig explicitly allows the keys on the
> > .machine keyrings, will the CA keys stored in MOK be loaded onto the
> > .machine keyring.
> >
> > Unfortunately I don't think there is any choice, but to define a new
> > MAINTAINERS entry. Perhaps something along the lines of:
> >
> > KEYS/KEYRINGS_INTEGRITY
> > M: Jarkko Sakkinen <[email protected]>
> > M: Mimi Zohar <[email protected]>
> > L: [email protected]
> > L: [email protected]
> > F: security/integrity/platform_certs
> >
>
> This would work for me.

Thanks, Jarkko. Are you planning on upstreaming this change, as you
previously said, or would you prefer I do it?

thanks,

Mimi

2022-02-22 12:47:46

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Tue, Feb 22, 2022 at 06:59:25AM -0500, Mimi Zohar wrote:
> On Sun, 2022-02-20 at 20:00 +0100, Jarkko Sakkinen wrote:
> > On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:
>
> > > >
> > > > Mimi brought up that we need a MAINTAINERS update for this and also
> > > > .platform.
> > > >
> > > > We have these:
> > > >
> > > > - KEYS/KEYRINGS
> > > > - CERTIFICATE HANDLING
> > > >
> > > > I would put them under KEYRINGS for now and would not consider further
> > > > subdivision for the moment.
> > >
> > > IMA has dependencies on the platform_certs/ and now on the new .machine
> > > keyring. Just adding "F: security/integrity/platform_certs/" to the
> > > KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
> > > even be on the linux-integrity mailing list.
> > >
> > > Existing requirement:
> > > - The keys on the .platform keyring are limited to verifying the kexec
> > > image.
> > >
> > > New requirements based on Eric Snowbergs' patch set:
> > > - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
> > > the MOK keys will not be loaded directly onto the .machine keyring or
> > > indirectly onto the .secondary_trusted_keys keyring.
> > >
> > > - Only when a new IMA Kconfig explicitly allows the keys on the
> > > .machine keyrings, will the CA keys stored in MOK be loaded onto the
> > > .machine keyring.
> > >
> > > Unfortunately I don't think there is any choice, but to define a new
> > > MAINTAINERS entry. Perhaps something along the lines of:
> > >
> > > KEYS/KEYRINGS_INTEGRITY
> > > M: Jarkko Sakkinen <[email protected]>
> > > M: Mimi Zohar <[email protected]>
> > > L: [email protected]
> > > L: [email protected]
> > > F: security/integrity/platform_certs
> > >
> >
> > This would work for me.
>
> Thanks, Jarkko. Are you planning on upstreaming this change, as you
> previously said, or would you prefer I do it?
>
> thanks,
>
> Mimi

This is the problem I'm encountering:

https://lore.kernel.org/keyrings/[email protected]/

BR, Jarkko

2022-02-22 13:09:41

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Tue, 2022-02-22 at 13:26 +0100, Jarkko Sakkinen wrote:
> On Tue, Feb 22, 2022 at 06:59:25AM -0500, Mimi Zohar wrote:
> > On Sun, 2022-02-20 at 20:00 +0100, Jarkko Sakkinen wrote:
> > > On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:
> >
> > > > >
> > > > > Mimi brought up that we need a MAINTAINERS update for this and also
> > > > > .platform.
> > > > >
> > > > > We have these:
> > > > >
> > > > > - KEYS/KEYRINGS
> > > > > - CERTIFICATE HANDLING
> > > > >
> > > > > I would put them under KEYRINGS for now and would not consider further
> > > > > subdivision for the moment.
> > > >
> > > > IMA has dependencies on the platform_certs/ and now on the new .machine
> > > > keyring. Just adding "F: security/integrity/platform_certs/" to the
> > > > KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
> > > > even be on the linux-integrity mailing list.
> > > >
> > > > Existing requirement:
> > > > - The keys on the .platform keyring are limited to verifying the kexec
> > > > image.
> > > >
> > > > New requirements based on Eric Snowbergs' patch set:
> > > > - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
> > > > the MOK keys will not be loaded directly onto the .machine keyring or
> > > > indirectly onto the .secondary_trusted_keys keyring.
> > > >
> > > > - Only when a new IMA Kconfig explicitly allows the keys on the
> > > > .machine keyrings, will the CA keys stored in MOK be loaded onto the
> > > > .machine keyring.
> > > >
> > > > Unfortunately I don't think there is any choice, but to define a new
> > > > MAINTAINERS entry. Perhaps something along the lines of:
> > > >
> > > > KEYS/KEYRINGS_INTEGRITY
> > > > M: Jarkko Sakkinen <[email protected]>
> > > > M: Mimi Zohar <[email protected]>
> > > > L: [email protected]
> > > > L: [email protected]
> > > > F: security/integrity/platform_certs
> > > >
> > >
> > > This would work for me.
> >
> > Thanks, Jarkko. Are you planning on upstreaming this change, as you
> > previously said, or would you prefer I do it?
> >
> This is the problem I'm encountering:
>
> https://lore.kernel.org/keyrings/[email protected]/

That's the answer to a different question. :) I was asking about the
MAINTAINERS record.

2022-02-22 15:38:29

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Tue, 2022-02-22 at 13:26 +0100, Jarkko Sakkinen wrote:
> This is the problem I'm encountering:
>
> https://lore.kernel.org/keyrings/[email protected]/

Try using the Message-Id: <
[email protected]>

--
thanks,

Mimi

2022-02-24 00:10:19

[permalink] [raw]

Subject: Re: [PATCH v10 0/8] Enroll kernel keys thru MOK

On Tue, Feb 22, 2022 at 07:32:20AM -0500, Mimi Zohar wrote:
> On Tue, 2022-02-22 at 13:26 +0100, Jarkko Sakkinen wrote:
> > On Tue, Feb 22, 2022 at 06:59:25AM -0500, Mimi Zohar wrote:
> > > On Sun, 2022-02-20 at 20:00 +0100, Jarkko Sakkinen wrote:
> > > > On Wed, Jan 26, 2022 at 05:06:09PM -0500, Mimi Zohar wrote:
> > >
> > > > > >
> > > > > > Mimi brought up that we need a MAINTAINERS update for this and also
> > > > > > .platform.
> > > > > >
> > > > > > We have these:
> > > > > >
> > > > > > - KEYS/KEYRINGS
> > > > > > - CERTIFICATE HANDLING
> > > > > >
> > > > > > I would put them under KEYRINGS for now and would not consider further
> > > > > > subdivision for the moment.
> > > > >
> > > > > IMA has dependencies on the platform_certs/ and now on the new .machine
> > > > > keyring. Just adding "F: security/integrity/platform_certs/" to the
> > > > > KEYS/KEYRINGS record, ignores that dependency. The discussion wouldn't
> > > > > even be on the linux-integrity mailing list.
> > > > >
> > > > > Existing requirement:
> > > > > - The keys on the .platform keyring are limited to verifying the kexec
> > > > > image.
> > > > >
> > > > > New requirements based on Eric Snowbergs' patch set:
> > > > > - When IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY is enabled,
> > > > > the MOK keys will not be loaded directly onto the .machine keyring or
> > > > > indirectly onto the .secondary_trusted_keys keyring.
> > > > >
> > > > > - Only when a new IMA Kconfig explicitly allows the keys on the
> > > > > .machine keyrings, will the CA keys stored in MOK be loaded onto the
> > > > > .machine keyring.
> > > > >
> > > > > Unfortunately I don't think there is any choice, but to define a new
> > > > > MAINTAINERS entry. Perhaps something along the lines of:
> > > > >
> > > > > KEYS/KEYRINGS_INTEGRITY
> > > > > M: Jarkko Sakkinen <[email protected]>
> > > > > M: Mimi Zohar <[email protected]>
> > > > > L: [email protected]
> > > > > L: [email protected]
> > > > > F: security/integrity/platform_certs
> > > > >
> > > >
> > > > This would work for me.
> > >
> > > Thanks, Jarkko. Are you planning on upstreaming this change, as you
> > > previously said, or would you prefer I do it?
> > >
> > This is the problem I'm encountering:
> >
> > https://lore.kernel.org/keyrings/[email protected]/
>
> That's the answer to a different question. :) I was asking about the
> MAINTAINERS record.

Aaaaa... sorry! Yeah, please do it :-)

BR, Jarkko

2022-02-24 01:43:13