KEYS: Make use of platform keyring for module signature verification

Message ID qvgp2il2co4iyxkzxvcs4p2bpyilqsbfgcprtpfrsajwae2etc@3z2s2o52i3xg
State New
Headers
Series KEYS: Make use of platform keyring for module signature verification |

Commit Message

Ahelenia Ziemiańska March 31, 2023, 2:30 p.m. UTC
  This allows a cert in DB to be used to sign modules,
in addition to certs in the MoK and built-in keyrings.

This key policy matches what's used for kexec.

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---

Notes:
    Debian has carried an equivalent patch since 5.3.9-1:
      https://bugs.debian.org/935945
      https://bugs.debian.org/1030200
    in
      https://salsa.debian.org/kernel-team/linux/-/commit/0e65c8f3e316d6f0fc30f091dd47dba2ac616529
    and it appears the true origin is some version of
      https://gitlab.com/cki-project/kernel-ark/-/commit/b697ff5e26974fee8fcd31a1e221e9dd41515efc

 kernel/module/signing.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)
  

Comments

Luis Chamberlain March 31, 2023, 8:01 p.m. UTC | #1
On Fri, Mar 31, 2023 at 04:30:21PM +0200, Ahelenia Ziemiańska wrote:
> This allows a cert in DB to be used to sign modules,
> in addition to certs in the MoK and built-in keyrings.
> 
> This key policy matches what's used for kexec.
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>

Before I nose dive, the commit log should explain why this patch never
was sent upstream, if it was, why it was rejected. What makes it good now?

Who is using it? What are other distributions doing about it?

  Luis
  
Ahelenia Ziemiańska March 31, 2023, 9:52 p.m. UTC | #2
On Fri, Mar 31, 2023 at 01:01:43PM -0700, Luis Chamberlain wrote:
> On Fri, Mar 31, 2023 at 04:30:21PM +0200, Ahelenia Ziemiańska wrote:
> > This allows a cert in DB to be used to sign modules,
> > in addition to certs in the MoK and built-in keyrings.
> > 
> > This key policy matches what's used for kexec.
> Before I nose dive, the commit log should explain why this patch never
> was sent upstream, if it was, why it was rejected. 
How would I know that?

Searching around on the list, I found an equivalent 2022-02-15 patch:
  https://lore.kernel.org/linux-kernel/840433bc93a58d6dfc4d96c34c0c3b158a0e669d.1644953683.git.msuchanek@suse.de/t/#u
and there's even a reply from you in there.

The discussion appears to boil down to
".platform is restricted to kexec",
"there are common setups in which it'd make much more sense to allow
 this, and also it's prety equivalent security-policy-wise",
(this repeats).

MoK/shim is also mentioned, for some reason, even though that solves a
different problem.

> What makes it good now?
Debian and Fedora are using it, and it's what users expect to work.

> Who is using it?
Debian (since 5.3.9-1, #935945) and Fedora (since the time of that bug
 at the very least, as Debian imported from there, so 2019-11-09).

> What are other distributions doing about it?
What does that mean, and also how would I know that?

Best,
  

Patch

diff --git a/kernel/module/signing.c b/kernel/module/signing.c
index a2ff4242e623..71d6248cf9ec 100644
--- a/kernel/module/signing.c
+++ b/kernel/module/signing.c
@@ -61,10 +61,16 @@  int mod_verify_sig(const void *mod, struct load_info *info)
 	modlen -= sig_len + sizeof(ms);
 	info->len = modlen;
 
-	return verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
-				      VERIFY_USE_SECONDARY_KEYRING,
-				      VERIFYING_MODULE_SIGNATURE,
-				      NULL, NULL);
+	ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+				     VERIFY_USE_SECONDARY_KEYRING,
+				     VERIFYING_MODULE_SIGNATURE,
+				     NULL, NULL);
+	if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
+		ret = verify_pkcs7_signature(mod, modlen, mod + modlen, sig_len,
+					     VERIFY_USE_PLATFORM_KEYRING,
+					     VERIFYING_MODULE_SIGNATURE,
+					     NULL, NULL);
+	return ret;
 }
 
 int module_sig_check(struct load_info *info, int flags)