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 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 the secondary trusted keyring. After the link is
created, keys contained in the .mok keyring will automatically be
searched when searching the 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
V3 changes:
- Only CA keys contained in the MOKList are loaded, nothing else
- Support for kernels built without the secondary trusted keyring
has been dropped.
[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 (14):
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_ca
integrity: accessor function to get trust_moklist
integrity: add new keyring handler for mok keys
KEYS: add a reference to mok keyring
KEYS: Introduce link restriction to include builtin, secondary and mok
keys
KEYS: change link restriction for secondary to also trust mok
KEYS: link secondary_trusted_keys to mok trusted keys
integrity: Do not allow mok keyring updates following init
integrity: store reference to mok keyring
integrity: change ima link restriction to include mok keys
certs/system_keyring.c | 33 ++++++-
crypto/asymmetric_keys/restrict.c | 40 +++++++++
include/crypto/public_key.h | 5 ++
include/keys/system_keyring.h | 10 +++
security/integrity/Makefile | 3 +-
security/integrity/digsig.c | 15 +++-
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, 220 insertions(+), 9 deletions(-)
create mode 100644 security/integrity/platform_certs/mok_keyring.c
base-commit: 36a21d51725af2ce0700c6ebcb6b9594aac658a6
--
2.18.4
The mok keyring is setup during init. No additional keys should be allowed
to be added afterwards. Leave the permission as read only.
Signed-off-by: Eric Snowberg <[email protected]>
---
v2: Initial version
v3: Unmodified from v2
---
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 ec94d564c68a..0601ef458e03 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -145,7 +145,8 @@ int __init integrity_init_keyring(const unsigned int id)
else
restriction->check = restrict_link_to_ima;
- perm |= KEY_USR_WRITE;
+ if (id != INTEGRITY_KEYRING_MOK)
+ perm |= KEY_USR_WRITE;
out:
return __integrity_init_keyring(id, perm, restriction);
--
2.18.4
With the introduction of the mok keyring, the end-user may choose to
trust Machine Owner Keys (MOK) within the kernel. If they have chosen to
trust them, the .mok keyring will contain these keys. If not, the mok
keyring will always be empty. Update the restriction check to allow the
ima keyring to also trust mok keys when the secondary keyring is also
trusted.
Signed-off-by: Eric Snowberg <[email protected]>
---
v3: Initial version
---
security/integrity/digsig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index 996bea950972..1419ff4fc2b9 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -34,7 +34,7 @@ static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
};
#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
-#define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
+#define restrict_link_to_ima restrict_link_by_builtin_secondary_and_ca_trusted
#else
#define restrict_link_to_ima restrict_link_by_builtin_trusted
#endif
--
2.18.4