Thread (26 messages) 26 messages, 4 authors, 2021-08-13
STALE1797d
Revisions (8)
  1. rfc [diff vs current]
  2. v2 [diff vs current]
  3. v3 current
  4. v4 [diff vs current]
  5. v5 [diff vs current]
  6. v6 [diff vs current]
  7. v7 [diff vs current]
  8. v8 [diff vs current]

[PATCH v3 10/14] KEYS: change link restriction for secondary to also trust mok

From: Eric Snowberg <eric.snowberg@oracle.com>
Date: 2021-08-12 02:21:08
Also in: keyrings, linux-crypto, linux-integrity, lkml
Subsystem: certificate handling, the rest · Maintainers: David Howells, David Woodhouse, Linus Torvalds

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
secondary trusted keyring to also trust mok keys.

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v3: Initial version
---
 certs/system_keyring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index cb773e09ea67..8cc19a1ff051 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -110,7 +110,7 @@ static __init struct key_restriction *get_builtin_and_secondary_restriction(void
 	if (!restriction)
 		panic("Can't allocate secondary trusted keyring restriction\n");
 
-	restriction->check = restrict_link_by_builtin_and_secondary_trusted;
+	restriction->check = restrict_link_by_builtin_secondary_and_ca_trusted;
 
 	return restriction;
 }
-- 
2.18.4
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help