LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com> To: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, zohar@linux.ibm.com, dhowells@redhat.com, dwmw2@infradead.org, herbert@gondor.apana.org.au, davem@davemloft.net, jarkko@kernel.org, jmorris@namei.org, serge@hallyn.com Cc: eric.snowberg@oracle.com, keescook@chromium.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, scott.branden@broadcom.com, weiyongjun1@huawei.com, nayna@linux.ibm.com, ebiggers@google.com, ardb@kernel.org, nramas@linux.microsoft.com, lszubowi@redhat.com, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linux-security-module@vger.kernel.org, James.Bottomley@HansenPartnership.com, pjones@redhat.com, glin@suse.com, konrad.wilk@oracle.com Subject: [PATCH v3 03/14] integrity: Trust MOK keys if MokListTrustedRT found Date: Wed, 11 Aug 2021 22:18:44 -0400 [thread overview] Message-ID: <20210812021855.3083178-4-eric.snowberg@oracle.com> (raw) In-Reply-To: <20210812021855.3083178-1-eric.snowberg@oracle.com> A new Machine Owner Key (MOK) variable called MokListTrustedRT has been introduced in shim. When this UEFI variable is set, it indicates the end-user has made the decision themself that they wish to trust MOK keys within the Linux trust boundary. It is not an error if this variable does not exist. If it does not exist, the MOK keys should not be trusted within the kernel. MOK variables are mirrored from Boot Services to Runtime Services. When shim sees the new MokTML BS variable, it will create a new variable (before Exit Boot Services is called) called MokListTrustedRT 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 MokListTrustedRT variable from Linux, the existence of EFI_VARIABLE_NON_VOLATILE will cause uefi_check_trust_mok_keys to return false. Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> --- v1: Initial version v2: Removed mok_keyring_trust_setup function v3: Unmodified from v2 --- .../integrity/platform_certs/mok_keyring.c | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/security/integrity/platform_certs/mok_keyring.c b/security/integrity/platform_certs/mok_keyring.c index b1ee45b77731..fe4f2d336260 100644 --- a/security/integrity/platform_certs/mok_keyring.c +++ b/security/integrity/platform_certs/mok_keyring.c @@ -5,6 +5,7 @@ * Copyright (c) 2021, Oracle and/or its affiliates. */ +#include <linux/efi.h> #include "../integrity.h" static __init int mok_keyring_init(void) @@ -19,3 +20,29 @@ static __init int mok_keyring_init(void) return 0; } device_initcall(mok_keyring_init); + +/* + * Try to load the MokListTrustedRT UEFI variable to see if we should trust + * the mok keys within the kernel. It is not an error if this variable + * does not exist. If it does not exist, mok keys should not be trusted + * within the kernel. + */ +static __init bool uefi_check_trust_mok_keys(void) +{ + efi_status_t status; + unsigned int mtrust = 0; + unsigned long size = sizeof(mtrust); + efi_guid_t guid = EFI_SHIM_LOCK_GUID; + u32 attr; + + status = efi.get_variable(L"MokListTrustedRT", &guid, &attr, &size, &mtrust); + + /* + * The EFI_VARIABLE_NON_VOLATILE check is to verify MokListTrustedRT + * was set thru shim mirrioring and not by a user from the host os. + * According to the UEFI spec, once EBS is performed, SetVariable() + * will succeed only when both EFI_VARIABLE_RUNTIME_ACCESS & + * EFI_VARIABLE_NON_VOLATILE are set. + */ + return (status == EFI_SUCCESS && (!(attr & EFI_VARIABLE_NON_VOLATILE))); +} -- 2.18.4
next prev parent reply other threads:[~2021-08-12 2:21 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-12 2:18 [PATCH v3 00/14] Enroll kernel keys thru MOK Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 01/14] integrity: Introduce a Linux keyring for the Machine Owner Key (MOK) Eric Snowberg 2021-08-12 18:58 ` Jarkko Sakkinen 2021-08-12 22:16 ` Eric Snowberg 2021-08-13 18:26 ` Nayna 2021-08-12 21:31 ` Mimi Zohar 2021-08-12 22:36 ` Eric Snowberg 2021-08-13 0:35 ` Mimi Zohar 2021-08-12 2:18 ` [PATCH v3 02/14] KEYS: CA link restriction Eric Snowberg 2021-08-12 2:18 ` Eric Snowberg [this message] 2021-08-12 2:18 ` [PATCH v3 04/14] integrity: add add_to_mok_keyring Eric Snowberg 2021-08-12 19:32 ` Jarkko Sakkinen 2021-08-12 22:04 ` Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 05/14] integrity: restrict INTEGRITY_KEYRING_MOK to restrict_link_by_ca Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 06/14] integrity: accessor function to get trust_moklist Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 07/14] integrity: add new keyring handler for mok keys Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 08/14] KEYS: add a reference to mok keyring Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 09/14] KEYS: Introduce link restriction to include builtin, secondary and mok keys Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok Eric Snowberg 2021-08-12 19:46 ` Mimi Zohar 2021-08-12 22:10 ` Eric Snowberg 2021-08-12 22:14 ` Mimi Zohar 2021-08-12 2:18 ` [PATCH v3 11/14] KEYS: link secondary_trusted_keys to mok trusted keys Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 12/14] integrity: Do not allow mok keyring updates following init Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 13/14] integrity: store reference to mok keyring Eric Snowberg 2021-08-12 2:18 ` [PATCH v3 14/14] integrity: change ima link restriction to include mok keys Eric Snowberg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210812021855.3083178-4-eric.snowberg@oracle.com \ --to=eric.snowberg@oracle.com \ --cc=James.Bottomley@HansenPartnership.com \ --cc=ardb@kernel.org \ --cc=davem@davemloft.net \ --cc=dhowells@redhat.com \ --cc=dwmw2@infradead.org \ --cc=ebiggers@google.com \ --cc=glin@suse.com \ --cc=gregkh@linuxfoundation.org \ --cc=herbert@gondor.apana.org.au \ --cc=jarkko@kernel.org \ --cc=jmorris@namei.org \ --cc=keescook@chromium.org \ --cc=keyrings@vger.kernel.org \ --cc=konrad.wilk@oracle.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=lszubowi@redhat.com \ --cc=nayna@linux.ibm.com \ --cc=nramas@linux.microsoft.com \ --cc=pjones@redhat.com \ --cc=scott.branden@broadcom.com \ --cc=serge@hallyn.com \ --cc=torvalds@linux-foundation.org \ --cc=weiyongjun1@huawei.com \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).