linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Snowberg <eric.snowberg@oracle.com>
To: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org
Cc: dhowells@redhat.com, dwmw2@infradead.org,
	dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com,
	jmorris@namei.org, jarkko@kernel.org,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, zohar@linux.ibm.com,
	torvalds@linux-foundation.org, serge@hallyn.com,
	James.Bottomley@HansenPartnership.com, pjones@redhat.com,
	glin@suse.com
Subject: [RFC PATCH 2/3] keys: Trust platform keyring if MokTrustPlatform found
Date: Mon, 17 May 2021 18:57:13 -0400	[thread overview]
Message-ID: <20210517225714.498032-3-eric.snowberg@oracle.com> (raw)
In-Reply-To: <20210517225714.498032-1-eric.snowberg@oracle.com>

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


  parent reply	other threads:[~2021-05-17 22:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 22:57 [RFC PATCH 0/3] Add additional MOK vars Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 1/3] keys: Add ability to trust the platform keyring Eric Snowberg
2021-05-20 15:59   ` Jarkko Sakkinen
2021-05-17 22:57 ` Eric Snowberg [this message]
2021-05-17 22:57 ` [RFC PATCH 3/3] ima: Enable IMA SB Policy if MokIMAPolicy found Eric Snowberg
2021-05-19  7:55 ` [RFC PATCH 0/3] Add additional MOK vars Jarkko Sakkinen
2021-05-19 14:32 ` Mimi Zohar
2021-05-19 22:04   ` Eric Snowberg
2021-05-20 12:22     ` Mimi Zohar
2021-05-20 20:37       ` Eric Snowberg
2021-05-21 11:44         ` Mimi Zohar
2021-05-24  0:57           ` Eric Snowberg
2021-05-24 11:12             ` Mimi Zohar
2021-06-01 15:24               ` Eric Snowberg
2021-05-24 10:09         ` Dr. Greg

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=20210517225714.498032-3-eric.snowberg@oracle.com \
    --to=eric.snowberg@oracle.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=glin@suse.com \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=pjones@redhat.com \
    --cc=serge@hallyn.com \
    --cc=torvalds@linux-foundation.org \
    --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: link
Be 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).