[RFC PATCH 0/3] Add additional MOK vars

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [2].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

This series adds two new MOK variables to shim. The first variable
allows the end-user to decide if they want to trust keys contained
within the platform keyring within the Linux trust boundary. By default,
nothing changes; platform keys are not trusted within the Linux kernel.
They are only trusted after the end-user makes the decision themself.
The end-user would set this through mokutil using a new --trust-platform
option [3]. This would work similar to how the kernel uses MOK variables
to enable/disable signature validation as well as use/ignore the db.

The second MOK variable allows a downstream Linux distro to make
better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

I have included links to both the mokutil [3] and shim [4] changes I
made to support this new functionality.

Thank you and looking forward to hearing your reviews.

[1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
[2] https://lore.kernel.org/patchwork/cover/902768/
[3] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars
[4] https://github.com/esnowberg/shim/tree/mokvars

Eric Snowberg (3):
  keys: Add ability to trust the platform keyring
  keys: Trust platform keyring if MokTrustPlatform found
  ima: Enable IMA SB Policy if MokIMAPolicy found

 certs/system_keyring.c                        | 19 ++++++++-
 include/keys/system_keyring.h                 | 10 +++++
 security/integrity/ima/Kconfig                |  8 ++++
 security/integrity/ima/ima_efi.c              | 24 ++++++++++++
 .../platform_certs/platform_keyring.c         | 39 +++++++++++++++++++
 5 files changed, 99 insertions(+), 1 deletion(-)

-- 
2.18.4

Add the ability to allow the secondary_trusted keyring to trust
keys in the platform keyring. This is done by doing a key_link
of the platform_trusted_keys to the secondary_trusted_keys.
After they are linked, the platform_trusted_keys can be used for
validation instead of the secondary_trusted_keys if the user
chooses. This functionality will be used in a follow on patch.

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

diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 4b693da488f1..471eb13e3cca 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c

@@ -23,6 +23,7 @@ static struct key *secondary_trusted_keys;
 #endif
 #ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
 static struct key *platform_trusted_keys;
+bool  secondary_trusts_platform;
 #endif
 
 extern __initconst const u8 system_certificate_list[];

@@ -67,6 +68,10 @@ int restrict_link_by_builtin_and_secondary_trusted(
 		/* Allow the builtin keyring to be added to the secondary */
 		return 0;
 
+	if (IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING) && secondary_trusts_platform)
+		return restrict_link_by_signature(dest_keyring, type, payload,
+						  platform_trusted_keys);
+
 	return restrict_link_by_signature(dest_keyring, type, payload,
 					  secondary_trusted_keys);
 }

@@ -227,7 +232,11 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
 		trusted_keys = builtin_trusted_keys;
 	} else if (trusted_keys == VERIFY_USE_SECONDARY_KEYRING) {
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
-		trusted_keys = secondary_trusted_keys;
+		if (IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING) &&
+		   secondary_trusts_platform)
+			trusted_keys = platform_trusted_keys;
+		else
+			trusted_keys = secondary_trusted_keys;
 #else
 		trusted_keys = builtin_trusted_keys;
 #endif

@@ -312,4 +321,12 @@ void __init set_platform_trusted_keys(struct key *keyring)
 {
 	platform_trusted_keys = keyring;
 }
+
+void __init set_trust_platform_keys(void)
+{
+	secondary_trusts_platform = true;
+
+	if (key_link(platform_trusted_keys, secondary_trusted_keys) < 0)
+		panic("Can't link trusted keyrings\n");
+}
 #endif

diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index fb8b07daa9d1..ffa5f0173ba8 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h

@@ -72,4 +72,14 @@ static inline void set_platform_trusted_keys(struct key *keyring)
 }
 #endif
 
+#if defined(CONFIG_INTEGRITY_PLATFORM_KEYRING) && \
+	defined(CONFIG_SYSTEM_TRUSTED_KEYRING) && \
+	defined(CONFIG_SECONDARY_TRUSTED_KEYRING)
+extern void __init set_trust_platform_keys(void);
+#else
+static inline void __init set_trust_platform_keys(void)
+{
+}
+#endif
+
 #endif /* _KEYS_SYSTEM_KEYRING_H */

-- 
2.18.4

A new MOK variable called MokIMAPolicy has been introduced in shim.
When this UEFI variable is set, it indicates the end-user has made
the decision that they wish to use the built-in kernel IMA architecture
specific policy base on the run time secure boot flags.

By default, this new MOK variable is not defined.  This causes the
IMA architecture specific secure boot policy to be disabled. Since
this changes the current behavior, a new Kconfig option called
IMA_UEFI_ARCH_POLICY has been added.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 security/integrity/ima/Kconfig   |  8 ++++++++
 security/integrity/ima/ima_efi.c | 24 ++++++++++++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 12e9250c1bec..3773d2d1ddc4 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig

@@ -172,6 +172,14 @@ config IMA_ARCH_POLICY
           This option enables loading an IMA architecture specific policy
           based on run time secure boot flags.
 
+config IMA_UEFI_ARCH_POLICY
+	bool "Enable IMA archecture specific policy thru a UEFI variable"
+	depends on IMA_ARCH_POLICY
+	default n
+	help
+	  This option allows the IMA archecture specific policy to be
+	  enabled or disabled thru a UEFI variable setup thru the shim.
+
 config IMA_APPRAISE_BUILD_POLICY
 	bool "IMA build time configured policy rules"
 	depends on IMA_APPRAISE && INTEGRITY_ASYMMETRIC_KEYS

diff --git a/security/integrity/ima/ima_efi.c b/security/integrity/ima/ima_efi.c
index 71786d01946f..46873a94c934 100644
--- a/security/integrity/ima/ima_efi.c
+++ b/security/integrity/ima/ima_efi.c

@@ -62,8 +62,32 @@ static const char * const sb_arch_rules[] = {
 	NULL
 };
 
+static __init int is_uefi_arch_policy_enabled(void)
+{
+	efi_status_t status;
+	unsigned int enabled = 0;
+	unsigned long size = sizeof(enabled);
+	efi_guid_t guid = EFI_SHIM_LOCK_GUID;
+	u32 attr;
+
+	status = efi.get_variable(L"MokIMAPolicy", &guid, &attr, &size, &enabled);
+
+	/*
+	 * The EFI_VARIABLE_NON_VOLATILE check is to verify MokIMAPolicy
+	 * was set thru the shim mirrioring and not by a user from the host os.
+	 * According to the UEFI spec, once EBS is performed, only variables
+	 * that have EFI_VARIABLE_RUNTIME_ACCESS & EFI_VARIABLE_NON_VOLATILE
+	 * set can be set with SetVariable().
+	 */
+	return (status == EFI_SUCCESS && (!(attr & EFI_VARIABLE_NON_VOLATILE)));
+}
+
 const char * const *arch_get_ima_policy(void)
 {
+	if (IS_ENABLED(CONFIG_IMA_UEFI_ARCH_POLICY))
+		if (!is_uefi_arch_policy_enabled())
+			return NULL;
+
 	if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot()) {
 		if (IS_ENABLED(CONFIG_MODULE_SIG))
 			set_module_sig_enforced();

-- 
2.18.4

A new MOK variable called MokTrustPlatform has been introduced in shim.
When this UEFI variable is set, it indicates the end-user has made the
decision themself that they wish to trust both UEFI Secure Boot
DB and MOK keys within the Linux trust boundary. It is not an error
if this variable does not exist.  If it does not exist, the platform
keyring should not be trusted within the kernel.

MOK variables are mirrored from Boot Services to Runtime Services. When
shim sees the new MokTPKState BS variable, it will create a variable
called MokTrustPlatform without EFI_VARIABLE_NON_VOLATILE set. Following
Exit Boot Services, UEFI variables can only be set and created
with SetVariable if both EFI_VARIABLE_RUNTIME_ACCESS &
EFI_VARIABLE_NON_VOLATILE are set.  Therefore, this can not be defeated
by simply creating a MokTrustPlatform variable from Linux, since
the existence of EFI_VARIABLE_NON_VOLATILE will cause
uefi_check_trust_platform to return false.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
 .../platform_certs/platform_keyring.c         | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/security/integrity/platform_certs/platform_keyring.c b/security/integrity/platform_certs/platform_keyring.c
index bcafd7387729..d2731182e511 100644
--- a/security/integrity/platform_certs/platform_keyring.c
+++ b/security/integrity/platform_certs/platform_keyring.c

@@ -13,6 +13,8 @@
 #include <linux/err.h>
 #include <linux/slab.h>
 #include "../integrity.h"
+#include <linux/efi.h>
+#include <keys/system_keyring.h>
 
 /**
  * add_to_platform_keyring - Add to platform keyring without validation.

@@ -37,6 +39,43 @@ void __init add_to_platform_keyring(const char *source, const void *data,
 		pr_info("Error adding keys to platform keyring %s\n", source);
 }
 
+/*
+ * Try to load the MokTrustPlatform UEFI variable to see if we should trust
+ * the platform keyring within the kernel. It is not an error if this variable
+ * does not exist.  If it does not exist, the platform keyring should not
+ * be trusted within the kernel.
+ */
+static __init bool uefi_check_trust_platform(void)
+{
+	efi_status_t status;
+	unsigned int ptrust = 0;
+	unsigned long size = sizeof(ptrust);
+	efi_guid_t guid = EFI_SHIM_LOCK_GUID;
+	u32 attr;
+
+	status = efi.get_variable(L"MokTrustPlatform", &guid, &attr, &size, &ptrust);
+
+	/*
+	 * The EFI_VARIABLE_NON_VOLATILE check is to verify MokTrustPlatform
+	 * was set thru the shim mirrioring and not by a user from the host os.
+	 * According to the UEFI spec, once EBS is performed, only variables
+	 * that have EFI_VARIABLE_RUNTIME_ACCESS & EFI_VARIABLE_NON_VOLATILE
+	 * set can be set with SetVariable().
+	 */
+	return (status == EFI_SUCCESS && (!(attr & EFI_VARIABLE_NON_VOLATILE)));
+}
+
+/*
+ * Check if the platform keyring should be trusted
+ */
+static __init void platform_keyring_trust_setup(void)
+{
+	if (uefi_check_trust_platform())
+		set_trust_platform_keys();
+}
+
+late_initcall(platform_keyring_trust_setup);
+
 /*
  * Create the trusted keyrings.
  */

-- 
2.18.4

On Mon, May 17, 2021 at 06:57:11PM -0400, Eric Snowberg wrote:

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [2].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

This series adds two new MOK variables to shim. The first variable
allows the end-user to decide if they want to trust keys contained

Nit: would be nice to just say "what it is" instead "what it allows".

within the platform keyring within the Linux trust boundary. By default,
nothing changes; platform keys are not trusted within the Linux kernel.
They are only trusted after the end-user makes the decision themself.
The end-user would set this through mokutil using a new --trust-platform
option [3]. This would work similar to how the kernel uses MOK variables
to enable/disable signature validation as well as use/ignore the db.

The second MOK variable allows a downstream Linux distro to make

...

better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

I have included links to both the mokutil [3] and shim [4] changes I
made to support this new functionality.

Thank you and looking forward to hearing your reviews.

[1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
[2] https://lore.kernel.org/patchwork/cover/902768/
[3] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars
[4] https://github.com/esnowberg/shim/tree/mokvars

Eric Snowberg (3):
  keys: Add ability to trust the platform keyring
  keys: Trust platform keyring if MokTrustPlatform found
  ima: Enable IMA SB Policy if MokIMAPolicy found

 certs/system_keyring.c                        | 19 ++++++++-
 include/keys/system_keyring.h                 | 10 +++++
 security/integrity/ima/Kconfig                |  8 ++++
 security/integrity/ima/ima_efi.c              | 24 ++++++++++++
 .../platform_certs/platform_keyring.c         | 39 +++++++++++++++++++
 5 files changed, 99 insertions(+), 1 deletion(-)

-- 
2.18.4

/Jarkko

Hi Eric,

On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote:

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [2].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

This series adds two new MOK variables to shim. The first variable
allows the end-user to decide if they want to trust keys contained
within the platform keyring within the Linux trust boundary. By default,
nothing changes; platform keys are not trusted within the Linux kernel.
They are only trusted after the end-user makes the decision themself.
The end-user would set this through mokutil using a new --trust-platform
option [3]. This would work similar to how the kernel uses MOK variables
to enable/disable signature validation as well as use/ignore the db.

The second MOK variable allows a downstream Linux distro to make
better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

I have included links to both the mokutil [3] and shim [4] changes I
made to support this new functionality.

Thank you and looking forward to hearing your reviews.

This patch set addresses two very different issues - allowing keys on
the platform keyring to be trusted for things other than verifying the
kexec kernel image signature, overwriting the arch specific IMA secure
boot policy rules.  The only common denominator is basing those
decisions on UEFI variables, which has been previously suggested and
rejected.  The threat model hasn't changed.

The desire for allowing a single local CA key to be loaded onto a
trusted keyring is understandable.  A local CA key can be used to sign
certificates, allowing them to be loaded onto the IMA keyring.  What is
the need for multiple keys? 

Making an exception for using a UEFI key for anything other than
verifying the kexec kernel image, can not be based solely on UEFI
variables, but should require some form of kernel
agreement/confirmation.  If/when a safe mechanism for identifying a
single local CA key is defined, the certificate should be loaded
directly onto the secondary keyring, not linked to the platform
keyring.

The system owner can enable/disable secure boot.  Disabling the arch
secure boot IMA policy rules is not needed.  However, another mechanism
for enabling them would be acceptable.

thanks,

Mimi

On May 19, 2021, at 8:32 AM, Mimi Zohar [off-list ref] wrote:

On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote:

quoted

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [2].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

This series adds two new MOK variables to shim. The first variable
allows the end-user to decide if they want to trust keys contained
within the platform keyring within the Linux trust boundary. By default,
nothing changes; platform keys are not trusted within the Linux kernel.
They are only trusted after the end-user makes the decision themself.
The end-user would set this through mokutil using a new --trust-platform
option [3]. This would work similar to how the kernel uses MOK variables
to enable/disable signature validation as well as use/ignore the db.

The second MOK variable allows a downstream Linux distro to make
better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

I have included links to both the mokutil [3] and shim [4] changes I
made to support this new functionality.

Thank you and looking forward to hearing your reviews.

This patch set addresses two very different issues - allowing keys on
the platform keyring to be trusted for things other than verifying the
kexec kernel image signature, overwriting the arch specific IMA secure
boot policy rules.  The only common denominator is basing those
decisions on UEFI variables, which has been previously suggested and
rejected.  The threat model hasn't changed.

Could you point me please to the previous discussion on the threat model
this change would violate?  What I found was [1], which I have tried to
solve with this series.  Having the ability to update a MOK variable 
indicates the user is not only root, but also the machine owner.  MOK 
variable updates require both root access to update and then physical 
presence to set via shim after reboot. This patch set tries to address 
the "*second* order" Linus requested [2].

The desire for allowing a single local CA key to be loaded onto a
trusted keyring is understandable.  A local CA key can be used to sign
certificates, allowing them to be loaded onto the IMA keyring.  What is
the need for multiple keys?

We have no control over how many keys an end-user may wish to enroll.  
They might want to enroll a CA for IMA and a different key for their 
kernel modules. This is a generic kernel that can serve many different 
purposes. Think distro kernels - like Fedora, Ubuntu, Oracle Linux, etc.

Making an exception for using a UEFI key for anything other than
verifying the kexec kernel image, can not be based solely on UEFI
variables, but should require some form of kernel
agreement/confirmation.  

Isn’t that the case today with how MOK variables get set through
mokutil and shim? 

If/when a safe mechanism for identifying a
single local CA key is defined, the certificate should be loaded
directly onto the secondary keyring, not linked to the platform
keyring.
The system owner can enable/disable secure boot.  Disabling the arch
secure boot IMA policy rules is not needed.  However, another mechanism
for enabling them would be acceptable.

For a distro kernel, disabling the arch secure boot IMA policy rules is 
needed.  Distributions build a single kernel that can be used in many 
different ways. If we wanted to add a built-in IMA policy for an extra 
level of security protection, this allows the end-user to opt-in when 
secure boot is enabled. They are then protected before init is called. 
Not every user will want this protection; a different user may just want 
secure boot enabled without the IMA level protection.

After going through the mailing list history related to IMA appraisal, 
is this feature strictly geared towards a custom kernel used for a 
specific purpose?  Do you view it as not being a feature suitable for 
a generic distribution kernel to offer? 


[1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
[2] https://marc.info/?l=linux-kernel&m=136185386310140&w=2

On Wed, 2021-05-19 at 16:04 -0600, Eric Snowberg wrote:

quoted

On May 19, 2021, at 8:32 AM, Mimi Zohar [off-list ref] wrote:

On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote:

quoted

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [2].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

This series adds two new MOK variables to shim. The first variable
allows the end-user to decide if they want to trust keys contained
within the platform keyring within the Linux trust boundary. By default,
nothing changes; platform keys are not trusted within the Linux kernel.
They are only trusted after the end-user makes the decision themself.
The end-user would set this through mokutil using a new --trust-platform
option [3]. This would work similar to how the kernel uses MOK variables
to enable/disable signature validation as well as use/ignore the db.

The second MOK variable allows a downstream Linux distro to make
better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

I have included links to both the mokutil [3] and shim [4] changes I
made to support this new functionality.

Thank you and looking forward to hearing your reviews.

This patch set addresses two very different issues - allowing keys on
the platform keyring to be trusted for things other than verifying the
kexec kernel image signature, overwriting the arch specific IMA secure
boot policy rules.  The only common denominator is basing those
decisions on UEFI variables, which has been previously suggested and
rejected.  The threat model hasn't changed.

Could you point me please to the previous discussion on the threat model
this change would violate?  What I found was [1], which I have tried to
solve with this series.  Having the ability to update a MOK variable 
indicates the user is not only root, but also the machine owner.  MOK 
variable updates require both root access to update and then physical 
presence to set via shim after reboot. This patch set tries to address 
the "*second* order" Linus requested [2].

The concern is not with the normal way of updating MOK.

quoted

The desire for allowing a single local CA key to be loaded onto a
trusted keyring is understandable.  A local CA key can be used to sign
certificates, allowing them to be loaded onto the IMA keyring.  What is
the need for multiple keys?

We have no control over how many keys an end-user may wish to enroll.  
They might want to enroll a CA for IMA and a different key for their 
kernel modules. This is a generic kernel that can serve many different 
purposes. Think distro kernels - like Fedora, Ubuntu, Oracle Linux, etc.

This patch set changes the secondary keyring root of trust, which is
currently the builtin or other keys on the secondary keyring.  My
concern with this change, is that any key on the secondary keyring may
then be directly loaded or used to verify other keys being loaded onto
the IMA keyring.

I really do understand the need for extending the root of trust beyond
the builtin keys and allowing end user keys to be loaded onto a kernel
keyring, but it needs to be done safely.  The first step might include
locally signing the MOK keys being loaded onto the secondary keyring
and then somehow safely providing the local-CA key id to the kernel.

quoted

Making an exception for using a UEFI key for anything other than
verifying the kexec kernel image, can not be based solely on UEFI
variables, but should require some form of kernel
agreement/confirmation.  

Isn’t that the case today with how MOK variables get set through
mokutil and shim? 

quoted

If/when a safe mechanism for identifying a
single local CA key is defined, the certificate should be loaded
directly onto the secondary keyring, not linked to the platform
keyring.
The system owner can enable/disable secure boot.  Disabling the arch
secure boot IMA policy rules is not needed.  However, another mechanism
for enabling them would be acceptable.

For a distro kernel, disabling the arch secure boot IMA policy rules is 
needed.  Distributions build a single kernel that can be used in many 
different ways. If we wanted to add a built-in IMA policy for an extra 
level of security protection, this allows the end-user to opt-in when 
secure boot is enabled. They are then protected before init is called. 
Not every user will want this protection; a different user may just want 
secure boot enabled without the IMA level protection.

When secure boot is enabled, the IMA arch policy rules verify the kexec
kernel image is properly signed.  When CONFIG_MODULE_SIG is not
configured, it also verifies kernel modules are properly signed.

After going through the mailing list history related to IMA appraisal, 
is this feature strictly geared towards a custom kernel used for a 
specific purpose?  Do you view it as not being a feature suitable for 
a generic distribution kernel to offer? 

IMA-appraisal is enabled by distros, but requires labeling the
filesystem with security.ima xattrs, before loading an appraisal
policy.

thanks,

Mimi

[1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/
[2] https://marc.info/?l=linux-kernel&m=136185386310140&w=2

On Mon, May 17, 2021 at 06:57:12PM -0400, Eric Snowberg wrote:

Add the ability to allow the secondary_trusted keyring to trust
keys in the platform keyring. This is done by doing a key_link

What this looks for me doing is to *replace* the secondary 
trusted keyring with the platform keyring.

So this should be "Add ability to replace the secondary trusted
keyring with the platform keyring." This is what the code change
is actually doing so it would be nice to say it out loud.

of the platform_trusted_keys to the secondary_trusted_keys.
After they are linked, the platform_trusted_keys can be used for
validation instead of the secondary_trusted_keys if the user
chooses. This functionality will be used in a follow on patch.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

/Jarkko 

On May 20, 2021, at 6:22 AM, Mimi Zohar [off-list ref] wrote:

On Wed, 2021-05-19 at 16:04 -0600, Eric Snowberg wrote:

quoted

quoted

On May 19, 2021, at 8:32 AM, Mimi Zohar [off-list ref] wrote:

On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote:

quoted

This series is being sent as an RFC. I am looking for feedback; if
adding additional MOK variables would be an acceptable solution to help
downstream Linux distros solve some of the problems we are facing?

Currently, pre-boot keys are not trusted within the Linux boundary [1].
Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These
keys are loaded into the platform keyring and can only be used for kexec.
If an end-user wants to use their own key within the Linux trust
boundary, they must either compile it into the kernel themselves or use
the insert-sys-cert script. Both options present a problem. Many
end-users do not want to compile their own kernels. With the
insert-sys-cert option, there are missing upstream changes [2].  Also,
with the insert-sys-cert option, the end-user must re-sign their kernel
again with their own key, and then insert that key into the MOK db.
Another problem with insert-sys-cert is that only a single key can be
inserted into a compressed kernel.

Having the ability to insert a key into the Linux trust boundary opens
up various possibilities.  The end-user can use a pre-built kernel and
sign their own kernel modules.  It also opens up the ability for an
end-user to more easily use digital signature based IMA-appraisal.  To
get a key into the ima keyring, it must be signed by a key within the
Linux trust boundary.

Downstream Linux distros try to have a single signed kernel for each
architecture.  Each end-user may use this kernel in entirely different
ways.  Some downstream kernels have chosen to always trust platform keys
within the Linux trust boundary.  In addition, most downstream kernels
do not have an easy way for an end-user to use digital signature based
IMA-appraisal.

This series adds two new MOK variables to shim. The first variable
allows the end-user to decide if they want to trust keys contained
within the platform keyring within the Linux trust boundary. By default,
nothing changes; platform keys are not trusted within the Linux kernel.
They are only trusted after the end-user makes the decision themself.
The end-user would set this through mokutil using a new --trust-platform
option [3]. This would work similar to how the kernel uses MOK variables
to enable/disable signature validation as well as use/ignore the db.

The second MOK variable allows a downstream Linux distro to make
better use of the IMA architecture specific Secure Boot policy.  This
IMA policy is enabled whenever Secure Boot is enabled.  By default, this 
new MOK variable is not defined.  This causes the IMA architecture 
specific Secure Boot policy to be disabled.  Since this changes the 
current behavior, it is placed behind a new Kconfig option.  Kernels
built with IMA_UEFI_ARCH_POLICY enabled would  allow the end-user
to enable this through mokutil using a new --ima-sb-enable option [3].
This gives the downstream Linux distro the capability to offer the
IMA architecture specific Secure Boot policy option, while giving
the end-user the ability to decide if they want to use it.

I have included links to both the mokutil [3] and shim [4] changes I
made to support this new functionality.

Thank you and looking forward to hearing your reviews.

This patch set addresses two very different issues - allowing keys on
the platform keyring to be trusted for things other than verifying the
kexec kernel image signature, overwriting the arch specific IMA secure
boot policy rules.  The only common denominator is basing those
decisions on UEFI variables, which has been previously suggested and
rejected.  The threat model hasn't changed.

Could you point me please to the previous discussion on the threat model
this change would violate?  What I found was [1], which I have tried to
solve with this series.  Having the ability to update a MOK variable 
indicates the user is not only root, but also the machine owner.  MOK 
variable updates require both root access to update and then physical 
presence to set via shim after reboot. This patch set tries to address 
the "*second* order" Linus requested [2].

The concern is not with the normal way of updating MOK.

quoted

quoted

The desire for allowing a single local CA key to be loaded onto a
trusted keyring is understandable.  A local CA key can be used to sign
certificates, allowing them to be loaded onto the IMA keyring.  What is
the need for multiple keys?

We have no control over how many keys an end-user may wish to enroll.  
They might want to enroll a CA for IMA and a different key for their 
kernel modules. This is a generic kernel that can serve many different 
purposes. Think distro kernels - like Fedora, Ubuntu, Oracle Linux, etc.

This patch set changes the secondary keyring root of trust, which is
currently the builtin or other keys on the secondary keyring.  My
concern with this change, is that any key on the secondary keyring may
then be directly loaded or used to verify other keys being loaded onto
the IMA keyring.

I understand the concern, that is why I left it up to the machine owner
to decide what they want to trust.  I took a quick look at a few other
distros, each one I checked (Red Hat, CentOS, Fedora, Ubuntu) all carry
this rejected patch [1]. These distributions have made the decision for
the end-user that they will trust platform keys for verifying kernel
modules.  With my change, it defaults to what the upstream maintainers
feel is an important trust model, but allows the end-user (assuming
they are the machine owner too) to override it.  This leaves the kernel
distributer out of the picture.

I really do understand the need for extending the root of trust beyond
the builtin keys and allowing end user keys to be loaded onto a kernel
keyring, but it needs to be done safely.  The first step might include
locally signing the MOK keys being loaded onto the secondary keyring
and then somehow safely providing the local-CA key id to the kernel.

If the machine owner and Linux distributor are independent of one another,
I don’t see how MOK key signing could work.  There wouldn’t be a way for
the kernel to verify the end-user supplied signed MOK key.  An end-user 
choosing a Linux distro is trusting the company/organization building the 
kernel, but the trust doesn’t go the other way.  Do you have a solution 
in mind on how this would be possible? If you do, I’m happy to move in
a different direction to solve this problem.

quoted

quoted

Making an exception for using a UEFI key for anything other than
verifying the kexec kernel image, can not be based solely on UEFI
variables, but should require some form of kernel
agreement/confirmation.  

Isn’t that the case today with how MOK variables get set through
mokutil and shim? 

quoted

If/when a safe mechanism for identifying a
single local CA key is defined, the certificate should be loaded
directly onto the secondary keyring, not linked to the platform
keyring.
The system owner can enable/disable secure boot.  Disabling the arch
secure boot IMA policy rules is not needed.  However, another mechanism
for enabling them would be acceptable.

For a distro kernel, disabling the arch secure boot IMA policy rules is 
needed.  Distributions build a single kernel that can be used in many 
different ways. If we wanted to add a built-in IMA policy for an extra 
level of security protection, this allows the end-user to opt-in when 
secure boot is enabled. They are then protected before init is called. 
Not every user will want this protection; a different user may just want 
secure boot enabled without the IMA level protection.

When secure boot is enabled, the IMA arch policy rules verify the kexec
kernel image is properly signed.  When CONFIG_MODULE_SIG is not
configured, it also verifies kernel modules are properly signed.

quoted

After going through the mailing list history related to IMA appraisal, 
is this feature strictly geared towards a custom kernel used for a 
specific purpose?  Do you view it as not being a feature suitable for 
a generic distribution kernel to offer? 

IMA-appraisal is enabled by distros, but requires labeling the
filesystem with security.ima xattrs, before loading an appraisal
policy.

I was referring to digital signature based IMA-appraisal.  If a company
wanted to ship a distro where all immutable files are IMA signed, today it
would not be feasible.  The end-user will undoubtably want to install their
own application, but this is not possible. The end-user can not IMA sign 
anything since they do not have the ability to add their own IMA CA.


[1] https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/

[Cc'ing Patrick Uiterwijk]

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:

quoted

On May 20, 2021, at 6:22 AM, Mimi Zohar [off-list ref] wrote:

quoted

I really do understand the need for extending the root of trust beyond
the builtin keys and allowing end user keys to be loaded onto a kernel
keyring, but it needs to be done safely.  The first step might include
locally signing the MOK keys being loaded onto the secondary keyring
and then somehow safely providing the local-CA key id to the kernel.

If the machine owner and Linux distributor are independent of one another,
I don’t see how MOK key signing could work.  There wouldn’t be a way for
the kernel to verify the end-user supplied signed MOK key.  An end-user 
choosing a Linux distro is trusting the company/organization building the 
kernel, but the trust doesn’t go the other way.  Do you have a solution 
in mind on how this would be possible? If you do, I’m happy to move in
a different direction to solve this problem.

We are working with the distros to address this problem.  The first
attempt at extending the secondary keyring's root of trust relied on a
TPM2 NV Index[1].

Using MOK is a possible alternative, if it can be done safely.  For
example, if the boot command line could be protected from modification,
the end-user could enroll a key in MOK and identify the specific MOK
key on the boot command line[2].  The boot command line would then
become an additional root of trust source.

The root of trust for loading keys on the different trusted keyrings
are self documenting -  restrict_link_by_builtin_trusted,
restrict_link_by_builtin_and_secondary_trusted().  A new function would
need to be defined to include the boot command line as a new or
additional root of trust source.
 
thanks,

Mimi

[1] https://lore.kernel.org/linux-integrity/20210225203229.363302-1-patrick@puiterwijk.org/
[2] Perhaps extend the existing "ca_keys" boot command line option.

On May 21, 2021, at 5:44 AM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:

quoted

quoted

On May 20, 2021, at 6:22 AM, Mimi Zohar [off-list ref] wrote:

quoted

quoted

I really do understand the need for extending the root of trust beyond
the builtin keys and allowing end user keys to be loaded onto a kernel
keyring, but it needs to be done safely.  The first step might include
locally signing the MOK keys being loaded onto the secondary keyring
and then somehow safely providing the local-CA key id to the kernel.

If the machine owner and Linux distributor are independent of one another,
I don’t see how MOK key signing could work.  There wouldn’t be a way for
the kernel to verify the end-user supplied signed MOK key.  An end-user 
choosing a Linux distro is trusting the company/organization building the 
kernel, but the trust doesn’t go the other way.  Do you have a solution 
in mind on how this would be possible? If you do, I’m happy to move in
a different direction to solve this problem.

We are working with the distros to address this problem.  The first
attempt at extending the secondary keyring's root of trust relied on a
TPM2 NV Index[1].

Yes, I saw that patch.  I view (which could be a mistake on my part) 
digital signature based IMA appraisal as an extension of a verified boot. 
Once a TPM is introduced, it is an extension of a measured boot. It seems 
like this patch is using measured boot to solve a problem that exists on 
the verified boot side. While it may be a good solution for someone using 
both measured boot and verified boot at the same time, not all machines or 
VMs contain a TPM. 

Using MOK is a possible alternative, if it can be done safely.

I do want to point out, in case this was missed, when the new MOK variable 
is set to trust the platform keyring, PCR14 gets extended [1]. The UEFI BS 
var MokTPKState is mirrored to a freshly created UEFI RT var called 
MokTrustPlatform.   The contents are extended into PCR14. This happens every 
time the system boots. The UEFI RT var does not persist across reboots, it 
is alway recreated by shim.  The same thing happens with keys in the MOKList.
Since the contents are mirrored, a key change can be detected on each boot. 
This makes it possible to use attestation to see if the system was booted 
with the proper variables set. For someone using measured boot, would this 
satisfy the requirement of safely protecting the system from a MOK update?

For example, if the boot command line could be protected from modification,
the end-user could enroll a key in MOK and identify the specific MOK
key on the boot command line[2].  The boot command line would then
become an additional root of trust source.

The root of trust for loading keys on the different trusted keyrings
are self documenting -  restrict_link_by_builtin_trusted,
restrict_link_by_builtin_and_secondary_trusted().  A new function would
need to be defined to include the boot command line as a new or
additional root of trust source.

[1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259

On Thu, May 20, 2021 at 02:37:31PM -0600, Eric Snowberg wrote:

Good morning, I hope the week is starting well for everyone.

quoted

On May 19, 2021, at 8:32 AM, Mimi Zohar [off-list ref] wrote:

quoted

After going through the mailing list history related to IMA appraisal, 
is this feature strictly geared towards a custom kernel used for a 
specific purpose?  Do you view it as not being a feature suitable for 
a generic distribution kernel to offer? 

IMA-appraisal is enabled by distros, but requires labeling the
filesystem with security.ima xattrs, before loading an appraisal
policy.

I was referring to digital signature based IMA-appraisal.  If a
company wanted to ship a distro where all immutable files are IMA
signed, today it would not be feasible.  The end-user will
undoubtably want to install their own application, but this is not
possible. The end-user can not IMA sign anything since they do not
have the ability to add their own IMA CA.

I've spent 6+ years working on this issue, with a focus on trusted
endpoint devices and their communications with trusted cloud
endpoints.

The challenge to trusted systems is that they not only have to be
secure, they have to be tractable for the general development
community to easily target, that is currently not the case.  Eric, as
you note, this extends to the notion of generic Linux distributions
being able to deliver this tractability and flexibility to their user
communities.

Making this happen requires a much more generic system for modeling
security behavior then what currently exists.  If one looks at how
security co-processors are going to evolve, this modeling will end up
going out of the kernel into external devices, which are not going to
be generic TPM's [*].

We have such an architecture for the 5.4 kernel, that with a little
luck, we hope to be able to release by mid-summer.  It peacefully
co-exists with all of the existing integrity infrastructure which
would make it tractable for a value add patch.

It includes a namespace implementation for the security event
modeling, without which, tractable trusted system development is a
non-starter.

If you are interested I will keep you in the loop.

Have a good day.

Greg

[*] We've used SGX enclaves and ST based micro-controller
implementations.

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"The vast majority of human beings dislike and even dread all notions
 with which they are not familiar.  Hence it comes about that at their
 first appearance innovators have always been derided as fools and
 madmen."
                                -- Aldous Huxley

On Sun, 2021-05-23 at 18:57 -0600, Eric Snowberg wrote:

quoted

On May 21, 2021, at 5:44 AM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:

quoted

quoted

On May 20, 2021, at 6:22 AM, Mimi Zohar [off-list ref] wrote:

quoted

quoted

I really do understand the need for extending the root of trust beyond
the builtin keys and allowing end user keys to be loaded onto a kernel
keyring, but it needs to be done safely.  The first step might include
locally signing the MOK keys being loaded onto the secondary keyring
and then somehow safely providing the local-CA key id to the kernel.

If the machine owner and Linux distributor are independent of one another,
I don’t see how MOK key signing could work.  There wouldn’t be a way for
the kernel to verify the end-user supplied signed MOK key.  An end-user 
choosing a Linux distro is trusting the company/organization building the 
kernel, but the trust doesn’t go the other way.  Do you have a solution 
in mind on how this would be possible? If you do, I’m happy to move in
a different direction to solve this problem.

We are working with the distros to address this problem.  The first
attempt at extending the secondary keyring's root of trust relied on a
TPM2 NV Index[1].

Yes, I saw that patch.  I view (which could be a mistake on my part) 
digital signature based IMA appraisal as an extension of a verified boot. 
Once a TPM is introduced, it is an extension of a measured boot. It seems 
like this patch is using measured boot to solve a problem that exists on 
the verified boot side. While it may be a good solution for someone using 
both measured boot and verified boot at the same time, not all machines or 
VMs contain a TPM. 

True, the TPM is used as part of measured boot, but that doesn't
prevent it from being used in other capacities.  In this case the TPM2
NV Index was used just to store a public key and safely used based on
TPM 2.0 rules.

quoted

Using MOK is a possible alternative, if it can be done safely.

I do want to point out, in case this was missed, when the new MOK variable 
is set to trust the platform keyring, PCR14 gets extended [1]. The UEFI BS 
var MokTPKState is mirrored to a freshly created UEFI RT var called 
MokTrustPlatform.   The contents are extended into PCR14. This happens every 
time the system boots. The UEFI RT var does not persist across reboots, it 
is alway recreated by shim.  The same thing happens with keys in the MOKList.
Since the contents are mirrored, a key change can be detected on each boot. 
This makes it possible to use attestation to see if the system was booted 
with the proper variables set. For someone using measured boot, would this 
satisfy the requirement of safely protecting the system from a MOK update?

TPM based trusted keys can be sealed to a TPM PCR.  Only if the PCRs
matched, is the private key unsealed.   In that case, measuring
provides the trust for releasing the private key.  In this case, just
measuring the UEFI MOK variable and key does not prevent an unknown
public key from being loaded onto a keyring.   Once loaded it could be
used to verify any signed code's signature.

Mimi

quoted

For example, if the boot command line could be protected from modification,
the end-user could enroll a key in MOK and identify the specific MOK
key on the boot command line[2].  The boot command line would then
become an additional root of trust source.

The root of trust for loading keys on the different trusted keyrings
are self documenting -  restrict_link_by_builtin_trusted,
restrict_link_by_builtin_and_secondary_trusted().  A new function would
need to be defined to include the boot command line as a new or
additional root of trust source.

[1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259

On May 24, 2021, at 5:12 AM, Mimi Zohar [off-list ref] wrote:

On Sun, 2021-05-23 at 18:57 -0600, Eric Snowberg wrote:

quoted

quoted

On May 21, 2021, at 5:44 AM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:

quoted

quoted

On May 20, 2021, at 6:22 AM, Mimi Zohar [off-list ref] wrote:

quoted

quoted

I really do understand the need for extending the root of trust beyond
the builtin keys and allowing end user keys to be loaded onto a kernel
keyring, but it needs to be done safely.  The first step might include
locally signing the MOK keys being loaded onto the secondary keyring
and then somehow safely providing the local-CA key id to the kernel.

If the machine owner and Linux distributor are independent of one another,
I don’t see how MOK key signing could work.  There wouldn’t be a way for
the kernel to verify the end-user supplied signed MOK key.  An end-user 
choosing a Linux distro is trusting the company/organization building the 
kernel, but the trust doesn’t go the other way.  Do you have a solution 
in mind on how this would be possible? If you do, I’m happy to move in
a different direction to solve this problem.

We are working with the distros to address this problem.  The first
attempt at extending the secondary keyring's root of trust relied on a
TPM2 NV Index[1].

Yes, I saw that patch.  I view (which could be a mistake on my part) 
digital signature based IMA appraisal as an extension of a verified boot. 
Once a TPM is introduced, it is an extension of a measured boot. It seems 
like this patch is using measured boot to solve a problem that exists on 
the verified boot side. While it may be a good solution for someone using 
both measured boot and verified boot at the same time, not all machines or 
VMs contain a TPM. 

True, the TPM is used as part of measured boot, but that doesn't
prevent it from being used in other capacities.  In this case the TPM2
NV Index was used just to store a public key and safely used based on
TPM 2.0 rules.

quoted

quoted

Using MOK is a possible alternative, if it can be done safely.

I do want to point out, in case this was missed, when the new MOK variable 
is set to trust the platform keyring, PCR14 gets extended [1]. The UEFI BS 
var MokTPKState is mirrored to a freshly created UEFI RT var called 
MokTrustPlatform.   The contents are extended into PCR14. This happens every 
time the system boots. The UEFI RT var does not persist across reboots, it 
is alway recreated by shim.  The same thing happens with keys in the MOKList.
Since the contents are mirrored, a key change can be detected on each boot. 
This makes it possible to use attestation to see if the system was booted 
with the proper variables set. For someone using measured boot, would this 
satisfy the requirement of safely protecting the system from a MOK update?

TPM based trusted keys can be sealed to a TPM PCR.  Only if the PCRs
matched, is the private key unsealed.   In that case, measuring
provides the trust for releasing the private key.  In this case, just
measuring the UEFI MOK variable and key does not prevent an unknown
public key from being loaded onto a keyring.   Once loaded it could be
used to verify any signed code's signature.

Correct, it does not prevent an unknown public key from being loaded into 
a keyring. Shim prevents unknown public keys from being added. Only the 
machine owner with physical presence can make these changes.  All keys 
shim loads into the MOKList get measured on each boot.

If an unknown public key could be loaded into MOK, shim could boot any 
kernel signed with it as well.  This kernel could be changed to load 
anything into the kernel keyring. So, I struggle to understand the 
difference; isn’t this exactly the same threat?

If an end-user wanted to protect against either case, they would need 
to construct a measured boot attestation policy that included PCR14 and 
took the host out of service if the PCR values didn’t match up.

quoted

quoted

For example, if the boot command line could be protected from modification,
the end-user could enroll a key in MOK and identify the specific MOK
key on the boot command line[2].  The boot command line would then
become an additional root of trust source.

The root of trust for loading keys on the different trusted keyrings
are self documenting -  restrict_link_by_builtin_trusted,
restrict_link_by_builtin_and_secondary_trusted().  A new function would
need to be defined to include the boot command line as a new or
additional root of trust source.

[1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259