From: Stefan Berger <stefanb@linux.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
David Howells <dhowells@redhat.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>,
"nayna@linux.ibm.com" <nayna@linux.ibm.com>,
"mic@linux.microsoft.com" <mic@linux.microsoft.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 4/4] integrity: CA enforcement in machine keyring
Date: Mon, 7 Mar 2022 13:36:44 -0500 [thread overview]
Message-ID: <571dbcce-e97f-fe4b-fdff-34f84a43e1a8@linux.ibm.com> (raw)
In-Reply-To: <64A87331-C97E-4565-B222-9BF7208E5010@oracle.com>
On 3/7/22 13:13, Eric Snowberg wrote:
>
>
>> On Mar 4, 2022, at 4:19 PM, Stefan Berger <stefanb@linux.ibm.com> wrote:
>>
>>
>> On 3/1/22 12:36, Eric Snowberg wrote:
>>> When INTEGRITY_MACHINE_KEYRING is set, all Machine Owner Keys (MOK)
>>> are loaded into the machine keyring. Add a new
>>> INTEGRITY_MACHINE_KEYRING_CA_ENFORCED option where only MOK CA keys are
>>> added.
>>>
>>> Set the restriction check to restrict_link_by_ca. This will only allow
>>> CA keys into the machine keyring. Unlike when INTEGRITY_MACHINE_KEYRING
>>> is enabled, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY may
>>> also be enabled, allowing IMA to use keys in the machine keyring as
>>> another trust anchor.
>>
>> I tried to test this but could only do it by disabling the MokListTrustedRT variable check and then also the check for secure boot. It did load the expected keys onto the .machine keyring, enforcing the x509 indicating a self-signed CA if the compile time option CONFIG_INTEGRITY_MACHINE_KEYRING_CA_ENFORCED=y was set, loading all keys in the case of CONFIG_INTEGRITY_MACHINE_KEYRING=y.
>>
>> I tried with this branch here from mokutils https://github.com/esnowberg/mokutil/tree/trust-mok but this seems to create an EFI variable with a different name. I guess this is the wrong branch?
>
> Thanks for testing. During the shim review, Peter requested an EFI variable name
> change. This did not impact anything in the kernel. However it did impact mokutil.
> The necessary mokutil changes are available in this pull request:
>
> https://github.com/lcp/mokutil/pull/49
>
The following is in Jarkko's tree:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=4d83e5144e224b90f6589d11b5fecde33c0dd211
+
+/*
+ * Try to load the MokListTrustedRT MOK 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 machine keyring.
+ */
+static __init bool uefi_check_trust_mok_keys(void)
+{
+ struct efi_mokvar_table_entry *mokvar_entry;
+
+ mokvar_entry = efi_mokvar_entry_find("MokListTrustedRT");
+
+ if (mokvar_entry)
+ return true;
+
+ return false;
+}
I don't think this works with your mokutil PR:
static int
trust_mok_keys()
{
return set_toggle("MokListTrustedNew", 0);
}
From what I saw, MokListTrustedRT searches for a mok-variable entry in
the MOK-specific directory in sysfs while MokListTrustedNew creates one
in the EFI dir...
Stefan
next prev parent reply other threads:[~2022-03-07 18:37 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-01 17:36 [PATCH 0/4] Add CA enforcement in the machine keyring Eric Snowberg
2022-03-01 17:36 ` [PATCH 1/4] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2022-03-01 17:36 ` [PATCH 2/4] X.509: Parse Basic Constraints for CA Eric Snowberg
2022-03-04 15:10 ` Stefan Berger
2022-03-07 18:02 ` Eric Snowberg
2022-03-01 17:36 ` [PATCH 3/4] KEYS: CA link restriction Eric Snowberg
2022-03-04 15:28 ` Stefan Berger
2022-03-07 18:06 ` Eric Snowberg
2022-03-07 23:01 ` Mimi Zohar
2022-03-07 23:38 ` Eric Snowberg
2022-03-08 2:31 ` Stefan Berger
2022-03-08 12:45 ` Mimi Zohar
2022-03-08 13:56 ` Stefan Berger
2022-03-08 18:02 ` Eric Snowberg
2022-03-09 17:12 ` Stefan Berger
2022-03-09 17:17 ` Stefan Berger
2022-03-09 18:13 ` Eric Snowberg
2022-03-09 19:02 ` Stefan Berger
2022-03-11 18:44 ` Eric Snowberg
2022-03-11 20:23 ` Stefan Berger
2022-03-14 12:00 ` Stefan Berger
2022-03-09 17:33 ` Mimi Zohar
2022-03-01 17:36 ` [PATCH 4/4] integrity: CA enforcement in machine keyring Eric Snowberg
2022-03-04 23:19 ` Stefan Berger
2022-03-07 18:13 ` Eric Snowberg
2022-03-07 18:36 ` Stefan Berger [this message]
2022-03-07 18:48 ` Eric Snowberg
2022-03-06 23:33 ` [PATCH 0/4] Add CA enforcement in the " Mimi Zohar
2022-03-07 18:55 ` Eric Snowberg
2022-03-09 18:43 ` Mimi Zohar
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=571dbcce-e97f-fe4b-fdff-34f84a43e1a8@linux.ibm.com \
--to=stefanb@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@linux.microsoft.com \
--cc=nayna@linux.ibm.com \
--cc=serge@hallyn.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: 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).