linux-kernel - Re: [GIT PULL] Asymmetric keys and module signing

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:	Tue, 02 Oct 2012 12:58:03 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Josh Boyer <jwboyer@...hat.com>,
	David Howells <dhowells@...hat.com>
Cc:	herbert@...dor.hengli.com.au, pjones@...hat.com,
	linux-crypto@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [GIT PULL] Asymmetric keys and module signing

Josh Boyer <jwboyer@...hat.com> writes:

> On Sat, Sep 29, 2012 at 08:13:25AM +0100, David Howells wrote:
>> Rusty Russell <rusty@...tcorp.com.au> wrote:
>> 
>> > [    2.808075] Loading module verification certificates
>> > [    2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired
>> > [    2.810500] MODSIGN: Problem loading in-kernel X.509 certificate (-127)
>> 
>> Hmmm...  Other people have seen that.
>> 
>> Ahhhhh!
>> 
>> I wonder if the problem is that the certificate is valid for 100 years....
>> That might well cause an overflow on a 32-bit system.
>
> That does seem quite plausible.  The comparisons are done with time_t,
> which boils down to 'long' and 100 years in seconds would overflow
> LONG_MAX.
>
>> Could you try changing the '36500' in kernel/Makefile to something shorter,
>> like 365?
>
> I tried two values today.  One close to LONG_MAX (24800 or ~68 years),
> and 10 years (3650).  The former still seemed to overflow, but
> specifying a 10yr lifetime appears to have worked.

That's because the timestamp is absolute, right?  Indeed, that seems to
be the limit here.

Here's my solution (tested, and it breaks if you change 2147300000 to
2147600000 as expected):

>From 2a4b91c2c29739191c6f7db9abee9296ae505c39 Mon Sep 17 00:00:00 2001
From: Rusty Russell <rusty@...tcorp.com.au>
Date: Tue, 2 Oct 2012 12:55:06 +0930
Subject: [PATCH] MODSIGN: fix expiry of auto-generated certificates on 32-bit
 systems

100-year certificates make time_t wrap, resulting in:

[    2.835272] X.509: Cert a94f6776f3f5483b0764011d1fcc6c0298362e63 has expired
[    2.836346] MODSIGN: Problem loading in-kernel X.509 certificate (-127)

Signed-off-by: Rusty Russell <rusty@...tcorp.com.au>

diff --git a/kernel/Makefile b/kernel/Makefile
index e951adf..86336c9 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -168,6 +168,13 @@ endif
 ifeq ($(sign_key_with_hash),)
 $(error Could not determine digest type to use from kernel config)
 endif
+ifeq ($(CONFIG_64BIT),y)
+# 100 years is beyond my best-before date, anyway.
+end_of_time_days=36500
+else
+# Until 32-bit time_t wraps, with some slack.
+end_of_time_days=$(shell expr \( 2147300000 - `date -u +%s` \) / 86400 )
+endif
 
 signing_key.priv signing_key.x509: x509.genkey
 	@echo "###"
@@ -180,7 +187,8 @@ signing_key.priv signing_key.x509: x509.genkey
 	@echo "###"
 	@echo "###     rngd -r /dev/hwrandom"
 	@echo "###"
-	openssl req -new -nodes -utf8 $(sign_key_with_hash) -days 36500 -batch \
+	openssl req -new -nodes -utf8 $(sign_key_with_hash) \
+		-days $(end_of_time_days) -batch \
 		-x509 -config x509.genkey \
 		-outform DER -out signing_key.x509 \
 		-keyout signing_key.priv
--
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/