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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 2 Oct 2012 08:17:04 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	David Howells <dhowells@...hat.com>, 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

On Tue, Oct 02, 2012 at 12:58:03PM +0930, Rusty Russell wrote:
> 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.

Yep.

> 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

That would likely work just fine.  David actually has another patch that
makes 100yrs still work on 32-bit as well that I've tested locally in a
KVM instance.  He was waiting on positive testing confirmation from me
so hopefully he'll send it soon.

josh
--
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/