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-user development kernel build. When Linux boots,
pre-boot keys (both UEFI Secure Boot DB and MOK keys) get loaded in the
Linux .platform keyring.
Currently, pre-boot keys are not trusted within the Linux trust boundary
[1]. These platform keys 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 for kernel module signing. These
kernels have no way of using digital signature base IMA appraisal.
This series introduces a new Linux kernel keyring containing the Machine
Owner Keys (MOK) called .mok. It also adds a new MOK variable to shim.
This variable allows the end-user to decide if they want to trust keys
enrolled in the MOK within the Linux trust boundary. By default,
nothing changes; MOK keys are not trusted within the Linux kernel. They
are only trusted after the end-user makes the decision themselves. The
end-user would set this through mokutil using a new --trust-mok 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.
When shim boots, it mirrors the new MokTML Boot Services variable to a
new MokListTrustedRT Runtime Services variable and extends PCR14.
MokListTrustedRT is written without EFI_VARIABLE_NON_VOLATILE set,
preventing an end-user from setting it after booting and doing a kexec.
When the kernel boots, if MokListTrustedRT is set and
EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
mok keyring instead of the platform keyring. Mimi has suggested that
only CA keys or keys that can be vouched for by other kernel keys be
loaded into this keyring. All other certs will load into the platform
keyring instead.
The .mok keyring contains a new keyring permission that only allows CA
keys to be loaded. If the permission fails, the key is later loaded into
the platform keyring. After all keys are added into the .mok keyring,
they are linked to either the builtin or secondary trusted keyring.
After the link is created, keys contained in the .mok keyring will
automatically be searched when searching either builtin or secondary
trusted keys.
Secure Boot keys will never be trusted. They will always be loaded into
the platform keyring. If an end-user wanted to trust one, they would
need to enroll it into the MOK.
I have included links to both the mokutil [3] and shim [4] changes I
have made to support this new functionality.
V2 changes:
- The .mok keyring persists past boot
- Removed the unrestricted move into the secondary keyring
- Removed the keyring move bypass patch
- Added restrictions to allow the .mok to be linked to either the
builtin or secondary keyrings
- Secondary keyring dependency has been removed
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/patchwork/cover/902768/
[3] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars-v2
[4] https://github.com/esnowberg/shim/tree/mokvars-v2
Eric Snowberg (12):
integrity: Introduce a Linux keyring for the Machine Owner Key (MOK)
KEYS: CA link restriction
integrity: Trust MOK keys if MokListTrustedRT found
integrity: add add_to_mok_keyring
integrity: restrict INTEGRITY_KEYRING_MOK to
restrict_link_by_system_trusted_or_ca
integrity: accessor function to get trust_moklist
integrity: add new keyring handler for mok keys
integrity: Suppress error message for keys added to the mok keyring
KEYS: add a reference to mok keyring
KEYS: link system_trusted_keys to mok_trusted_keys
integrity: Do not allow mok keyring updates following init
integrity: store reference to mok keyring
certs/system_keyring.c | 47 ++++++++++
crypto/asymmetric_keys/restrict.c | 60 +++++++++++++
include/crypto/public_key.h | 5 ++
include/keys/system_keyring.h | 10 +++
security/integrity/Makefile | 3 +-
security/integrity/digsig.c | 16 +++-
security/integrity/integrity.h | 12 ++-
.../platform_certs/keyring_handler.c | 17 +++-
.../platform_certs/keyring_handler.h | 5 ++
security/integrity/platform_certs/load_uefi.c | 4 +-
.../integrity/platform_certs/mok_keyring.c | 85 +++++++++++++++++++
11 files changed, 256 insertions(+), 8 deletions(-)
create mode 100644 security/integrity/platform_certs/mok_keyring.c
base-commit: ff1176468d368232b684f75e82563369208bc371
--
2.18.4
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.
Add a new Linux keyring called .mok. This keyring shall contain just
MOK keys and not the remaining keys in the platform keyring. This new
.mok keyring will be used in follow on patches. Unlike keys in the
platform keyring, keys contained in the .mok keyring will be trusted
within the kernel if the end-user has chosen to do so.
Signed-off-by: Eric Snowberg <[email protected]>
---
v1: Initial version
v2: Removed destory keyring code
---
security/integrity/Makefile | 3 ++-
security/integrity/digsig.c | 1 +
security/integrity/integrity.h | 3 ++-
.../integrity/platform_certs/mok_keyring.c | 21 +++++++++++++++++++
4 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 security/integrity/platform_certs/mok_keyring.c
diff --git a/security/integrity/Makefile b/security/integrity/Makefile
index 7ee39d66cf16..8e2e98cba1f6 100644
--- a/security/integrity/Makefile
+++ b/security/integrity/Makefile
@@ -9,7 +9,8 @@ integrity-y := iint.o
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_PLATFORM_KEYRING) += platform_certs/platform_keyring.o \
+ platform_certs/mok_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..e07334504ef1 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",
+ ".mok",
};
#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 547425c20e11..e0e17ccba2e6 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_MOK 3
+#define INTEGRITY_KEYRING_MAX 4
extern struct dentry *integrity_dir;
diff --git a/security/integrity/platform_certs/mok_keyring.c b/security/integrity/platform_certs/mok_keyring.c
new file mode 100644
index 000000000000..b1ee45b77731
--- /dev/null
+++ b/security/integrity/platform_certs/mok_keyring.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MOK keyring routines.
+ *
+ * Copyright (c) 2021, Oracle and/or its affiliates.
+ */
+
+#include "../integrity.h"
+
+static __init int mok_keyring_init(void)
+{
+ int rc;
+
+ rc = integrity_init_keyring(INTEGRITY_KEYRING_MOK);
+ if (rc)
+ return rc;
+
+ pr_notice("MOK Keyring initialized\n");
+ return 0;
+}
+device_initcall(mok_keyring_init);
--
2.18.4
Expose the .mok keyring created in integrity code by adding
a reference. This makes the mok keyring accessible for keyring
restrictions in the future.
Signed-off-by: Eric Snowberg <[email protected]>
---
v2: Initial version
---
certs/system_keyring.c | 5 +++++
include/keys/system_keyring.h | 4 ++++
2 files changed, 9 insertions(+)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 0a7b16c28a72..dcaf74102ab2 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -27,6 +27,7 @@ static struct key *secondary_trusted_keys;
#endif
#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
static struct key *platform_trusted_keys;
+static struct key *mok_trusted_keys;
#endif
extern __initconst const u8 system_certificate_list[];
@@ -317,4 +318,8 @@ void __init set_platform_trusted_keys(struct key *keyring)
{
platform_trusted_keys = keyring;
}
+void __init set_mok_trusted_keys(struct key *keyring)
+{
+ mok_trusted_keys = keyring;
+}
#endif
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 2041254d74f4..1adf78ddc035 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -94,10 +94,14 @@ static inline struct key *get_ima_blacklist_keyring(void)
#if defined(CONFIG_INTEGRITY_PLATFORM_KEYRING) && \
defined(CONFIG_SYSTEM_TRUSTED_KEYRING)
extern void __init set_platform_trusted_keys(struct key *keyring);
+extern void __init set_mok_trusted_keys(struct key *keyring);
#else
static inline void set_platform_trusted_keys(struct key *keyring)
{
}
+static void __init set_mok_trusted_keys(struct key *keyring)
+{
+}
#endif
#endif /* _KEYS_SYSTEM_KEYRING_H */
--
2.18.4
Suppress the error message for keys added to the mok keyring. If an
error occurs, the key will be added to the platform keyring instead.
Signed-off-by: Eric Snowberg <[email protected]>
---
v1: Initial version
v2: Unmodified from v1
---
security/integrity/digsig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 2f6898c89f60..be4860c596b9 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -165,7 +165,8 @@ static int __init integrity_add_key(const unsigned int id, const void *data,
KEY_ALLOC_NOT_IN_QUOTA);
if (IS_ERR(key)) {
rc = PTR_ERR(key);
- pr_err("Problem loading X.509 certificate %d\n", rc);
+ if (id != INTEGRITY_KEYRING_MOK)
+ pr_err("Problem loading X.509 certificate %d\n", rc);
} else {
pr_notice("Loaded X.509 cert '%s'\n",
key_ref_to_ptr(key)->description);
--
2.18.4
Add an accessor function to see if the mok list should be trusted.
Signed-off-by: Eric Snowberg <[email protected]>
---
v1: Initial version
v2: Added trust_moklist function
---
security/integrity/integrity.h | 5 +++++
security/integrity/platform_certs/mok_keyring.c | 16 ++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/security/integrity/integrity.h b/security/integrity/integrity.h
index 60d5c7ba05b2..1fcefceb0da1 100644
--- a/security/integrity/integrity.h
+++ b/security/integrity/integrity.h
@@ -279,6 +279,7 @@ integrity_audit_log_start(struct audit_context *ctx, gfp_t gfp_mask, int type)
void __init add_to_platform_keyring(const char *source, const void *data,
size_t len);
void __init add_to_mok_keyring(const char *source, const void *data, size_t len);
+bool __init trust_moklist(void);
#else
static inline void __init add_to_platform_keyring(const char *source,
const void *data, size_t len)
@@ -287,4 +288,8 @@ static inline void __init add_to_platform_keyring(const char *source,
void __init add_to_mok_keyring(const char *source, const void *data, size_t len)
{
}
+static inline bool __init trust_moklist(void)
+{
+ return false;
+}
#endif
diff --git a/security/integrity/platform_certs/mok_keyring.c b/security/integrity/platform_certs/mok_keyring.c
index f260edac0863..c7820d9136f3 100644
--- a/security/integrity/platform_certs/mok_keyring.c
+++ b/security/integrity/platform_certs/mok_keyring.c
@@ -8,6 +8,8 @@
#include <linux/efi.h>
#include "../integrity.h"
+bool trust_mok;
+
static __init int mok_keyring_init(void)
{
int rc;
@@ -67,3 +69,17 @@ static __init bool uefi_check_trust_mok_keys(void)
*/
return (status == EFI_SUCCESS && (!(attr & EFI_VARIABLE_NON_VOLATILE)));
}
+
+bool __init trust_moklist(void)
+{
+ static bool initialized;
+
+ if (!initialized) {
+ initialized = true;
+
+ if (uefi_check_trust_mok_keys())
+ trust_mok = true;
+ }
+
+ return trust_mok;
+}
--
2.18.4
> On Aug 3, 2021, at 11:01 AM, Mimi Zohar <[email protected]> wrote:
>
> On Mon, 2021-07-26 at 13:13 -0400, Eric Snowberg wrote:
>
>> When the kernel boots, if MokListTrustedRT is set and
>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
>> mok keyring instead of the platform keyring. Mimi has suggested that
>> only CA keys or keys that can be vouched for by other kernel keys be
>> loaded into this keyring. All other certs will load into the platform
>> keyring instead.
>
> I suggested only loading the CA keys stored in the MOK db onto the MOK
> keyring. Like the builtin trusted keyring, the MOK keyring would also
> be linked to the secondary keyring. Assuming the secondary keyring is
> defined, all other properly signed MOK db keys - signed by keys on the
> builtin, secondary or MOK keyring - would be loaded onto the secondary
> keyring.
>
> As previously discussed, this might require reading the MOK db twice -
> once to load the CA keys on the MOK keyring, a second time to load the
> remaining properly signed keys onto the secondary keyring.
I’m only loading CA keys or keys that can be vouched for by other kernel
keys into the new mok keyring. Currently, I’m not doing another pass. I
could add another pass, but it would not solve the issue with someone trying
to load an intermediate CA along with a leaf cert. This would require yet
a third pass. I wasn’t sure if this added complexity was necessary.
Currently, any CA contained within the MOK db would now be trusted by the
kernel. Someone using a kernel with the secondary keyring enabled could
load the intermediate and leaf certs themselves following boot. Taking
this into account, if you’d like to see two passes, let me know and I’ll add
that in v3. If a second pass is done, do you really want these additional
keys added to the secondary keyring or should they go into the mok keyring
instead? I was under the impression the secondary should be empty until a
user adds their own keys into it. Thanks.
Hi Eric,
On Tue, 2021-08-03 at 13:52 -0600, Eric Snowberg wrote:
> > On Aug 3, 2021, at 11:01 AM, Mimi Zohar <[email protected]> wrote:
> >
> > On Mon, 2021-07-26 at 13:13 -0400, Eric Snowberg wrote:
> >
> >> When the kernel boots, if MokListTrustedRT is set and
> >> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
> >> mok keyring instead of the platform keyring. Mimi has suggested that
> >> only CA keys or keys that can be vouched for by other kernel keys be
> >> loaded into this keyring. All other certs will load into the platform
> >> keyring instead.
> >
> > I suggested only loading the CA keys stored in the MOK db onto the MOK
> > keyring. Like the builtin trusted keyring, the MOK keyring would also
> > be linked to the secondary keyring. Assuming the secondary keyring is
> > defined, all other properly signed MOK db keys - signed by keys on the
> > builtin, secondary or MOK keyring - would be loaded onto the secondary
> > keyring.
> >
> > As previously discussed, this might require reading the MOK db twice -
> > once to load the CA keys on the MOK keyring, a second time to load the
> > remaining properly signed keys onto the secondary keyring.
>
> I’m only loading CA keys or keys that can be vouched for by other kernel
> keys into the new mok keyring.
The cover letter implies that this suggestion is coming from me, which
it definitely is not. My preference, as I made clear from the very
beginning, is to load ONLY the MOK DB CA keys onto the mok
keyring. (And even go one step farther, requiring the MOK DB CA
key(s) to be identified on the boot command line.)
> Currently, I’m not doing another pass. I
> could add another pass, but it would not solve the issue with someone trying
> to load an intermediate CA along with a leaf cert. This would require yet
> a third pass. I wasn’t sure if this added complexity was necessary.
>
> Currently, any CA contained within the MOK db would now be trusted by the
> kernel. Someone using a kernel with the secondary keyring enabled could
> load the intermediate and leaf certs themselves following boot.
Correct, as previously discussed, the other signed MOK DB keys may be
loaded by userspace. The only reason we're interested in any of the
other MOK DB keys is prevent a regression. As you previously pointed
out all of the MOK DB keys are currently being loaded onto the platform
keyring. So leave the existing code, which loads the MOK DB keys onto
the platform keyring, alone to prevent that regression. It's already
being controlled by a UEFI variable.
> Taking
> this into account, if you’d like to see two passes, let me know and I’ll add
> that in v3. If a second pass is done, do you really want these additional
> keys added to the secondary keyring or should they go into the mok keyring
> instead? I was under the impression the secondary should be empty until a
> user adds their own keys into it. Thanks.
Again, my preference would be to load ONLY the MOK DB CA keys onto the
mok keyring.
If YOU decide you want to load the signed keys stored in MOK DB, be my
guest. However, they should be loaded onto the secondary keyring and a
new restriction defined, similar to
"restrict_link_by_builtin_and_secondary_trusted", which includes mok as
well.
thanks,
Mimi
> On Aug 3, 2021, at 7:14 PM, Mimi Zohar <[email protected]> wrote:
>
> On Tue, 2021-08-03 at 13:52 -0600, Eric Snowberg wrote:
>>> On Aug 3, 2021, at 11:01 AM, Mimi Zohar <[email protected]> wrote:
>>>
>>> On Mon, 2021-07-26 at 13:13 -0400, Eric Snowberg wrote:
>>>
>>>> When the kernel boots, if MokListTrustedRT is set and
>>>> EFI_VARIABLE_NON_VOLATILE is not set, the MokListRT is loaded into the
>>>> mok keyring instead of the platform keyring. Mimi has suggested that
>>>> only CA keys or keys that can be vouched for by other kernel keys be
>>>> loaded into this keyring. All other certs will load into the platform
>>>> keyring instead.
>>>
>>> I suggested only loading the CA keys stored in the MOK db onto the MOK
>>> keyring. Like the builtin trusted keyring, the MOK keyring would also
>>> be linked to the secondary keyring. Assuming the secondary keyring is
>>> defined, all other properly signed MOK db keys - signed by keys on the
>>> builtin, secondary or MOK keyring - would be loaded onto the secondary
>>> keyring.
>>>
>>> As previously discussed, this might require reading the MOK db twice -
>>> once to load the CA keys on the MOK keyring, a second time to load the
>>> remaining properly signed keys onto the secondary keyring.
>>
>> I’m only loading CA keys or keys that can be vouched for by other kernel
>> keys into the new mok keyring.
>
> The cover letter implies that this suggestion is coming from me, which
> it definitely is not. My preference, as I made clear from the very
> beginning, is to load ONLY the MOK DB CA keys onto the mok
> keyring. (And even go one step farther, requiring the MOK DB CA
> key(s) to be identified on the boot command line.)
Ok, got it. I guess I misunderstood and was thinking built-in should be
referenced too for things going into the new mok keyring.
>> Currently, I’m not doing another pass. I
>> could add another pass, but it would not solve the issue with someone trying
>> to load an intermediate CA along with a leaf cert. This would require yet
>> a third pass. I wasn’t sure if this added complexity was necessary.
>>
>> Currently, any CA contained within the MOK db would now be trusted by the
>> kernel. Someone using a kernel with the secondary keyring enabled could
>> load the intermediate and leaf certs themselves following boot.
>
> Correct, as previously discussed, the other signed MOK DB keys may be
> loaded by userspace. The only reason we're interested in any of the
> other MOK DB keys is prevent a regression. As you previously pointed
> out all of the MOK DB keys are currently being loaded onto the platform
> keyring. So leave the existing code, which loads the MOK DB keys onto
> the platform keyring, alone to prevent that regression. It's already
> being controlled by a UEFI variable.
With this series, I do not believe a regression exists. With a single pass,
keys are either loaded into the mok or the platform keyring. Since the mok
is linked to the secondary (or the built-in), during kexec signature validation,
all keys are referenced.
>> Taking
>> this into account, if you’d like to see two passes, let me know and I’ll add
>> that in v3. If a second pass is done, do you really want these additional
>> keys added to the secondary keyring or should they go into the mok keyring
>> instead? I was under the impression the secondary should be empty until a
>> user adds their own keys into it. Thanks.
>
> Again, my preference would be to load ONLY the MOK DB CA keys onto the
> mok keyring.
Ok, I’ll update the current code to just load CA keys into the mok in v3. This would
simplify the new restrict_link_by_ca function.
With that change, do you see any issues with how I’m doing the linking? With the
mok keyring linked to the secondary keyring, the platform keyring may only contain
a subset of the keys it originally contained. But, as I described above, I don’t believe
it will lead to a regression since all keys get referenced. Thanks.
On Wed, 2021-08-04 at 02:56 +0000, Eric Snowberg wrote:
> Ok, I’ll update the current code to just load CA keys into the mok in v3. This would
> simplify the new restrict_link_by_ca function.
Thank you!
>
> With that change, do you see any issues with how I’m doing the linking? With the
> mok keyring linked to the secondary keyring, the platform keyring may only contain
> a subset of the keys it originally contained. But, as I described above, I don’t believe
> it will lead to a regression since all keys get referenced. Thanks.
I think there is a problem. Only the builtin keys should ever be on
the builtin keyring. The builtin keyring would need to be linked to
the mok keyring. But in the secondary keyring case, the linking
should be the reverse, where the mok keyring would be linked to the
secondary keyring, similar to how the builtin keyring is linked to the
secondary keyring.
if (key_link(secondary_trusted_keys, builtin_trusted_keys) < 0)
panic("Can't link trusted keyrings\n");
thanks,
Mimi