linux-kernel - Re: [PATCH] MODSIGN: Change default key details [ver #2]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri,  1 May 2015 17:41:45 -0400
From:	Abelardo Ricart III <aricart@...nix.com>
To:	torvalds@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, sedat.dilek@...il.com,
	dhowells@...hat.com, keyrings@...ux-nfs.org, rusty@...tcorp.com.au,
	linux-security-module@...r.kernel.org, james.l.morris@...cle.com,
	gregkh@...uxfoundation.org,
	Abelardo Ricart III <aricart@...nix.com>
Subject: Re: [PATCH] MODSIGN: Change default key details [ver #2]

Forgive me if this git send-email blows up in my face somehow, as I hadn't been subscribed to this list before this reply.

I had some similar and probably related behavior I submitted a patch to the kbuild guys for that fell on deaf ears. Basically, I think an order-only prerequisite would make the most sense in this case because right now the key generation target is going to trigger any time the x509.genkey file has its timestamp touched to where it becomes "newer" than our keys, even if its content remains the same.

What if I provided my own keys already, as module-signing.txt said was okay? What if the autogenerated keys from my last build still exist?

>From module-signing.txt:

> Under normal conditions, the kernel build will automatically generate a new
> keypair using openssl if one does not exist in the files:
>
>	 signing_key.priv
>	 signing_key.x509

Nope, sorry, not true. Even if your keys exist, due to unfortunate parallel make/disk write order/racy kbuild/goblins your x509.genkey file has a newer timestamp than your keys, and now your keys are going to get tossed (regenerated and overwritten, yay!). Worse still, I think they could even get tossed AFTER the build decides "hey nice keys, I'll just use those". Either way, this patch is ultimately correct because this is exactly the kind of racy scenario order-only prerequisites was made for. We should not care anything about x509.genkey if our signing keys already exist. Period.

Here's my two-line patch strictly defining the build order, for your perusal.

Signed-off-by: Abelardo Ricart III <aricart@...nix.com>
---

diff --git a/kernel/Makefile b/kernel/Makefile
index 1408b33..10c8df0 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -168,7 +168,8 @@ ifndef CONFIG_MODULE_SIG_HASH
 $(error Could not determine digest type to use from kernel config)
 endif

-signing_key.priv signing_key.x509: x509.genkey
+signing_key.priv signing_key.x509: | x509.genkey
+       $(warning *** X.509 module signing key pair not found in root of source tree ***)
        @echo "###"
        @echo "### Now generating an X.509 key pair to be used for signing modules."
        @echo "###"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/