Re: Wrong system clock vs X.509 date specifiers

[David Woodhouse]

On Tue, 2012-09-25 at 16:30 +0100, Alan Cox wrote:
> On Tue, 25 Sep 2012 16:09:54 +0100
> David Howells <dhowells@xxxxxxxxxx> wrote:
> 
> > 
> > The X.509 certificate has a pair of times in it that delineate the valid
> > period of the cert, and I'm checking that the system clock is within the
> > bounds they define before permitting you to use the cert.  I've been setting
> > the expiry date to be 100 years in the future - by which time hopefully I
> > won't have to worry about it - but occasionally clock skew means a freshly
> > built kernel won't boot because the machine trying to boot doesn't think that
> > the start time has been reached yet.
> > 
> > Do we actually want to do this, however?  Or should we just ignore the times?
> > Or just the start time?
> 
> Generate a certificate that is valid from a few minutes before the
> wallclock time. It's a certificate policy question not a kernel hackery
> one.

That's not good enough. I frequently encounter laptops with hardware
clocks which are *way* slower than that. I see lots of machines booting
up thinking it's 1970, 1900 iirc for some Macs, and more recently 2001.

This causes the kernel to refuse to load the certificate:
[    3.116185] Loading module verification certificates
[    3.117414] X.509: Cert e1a74f2317b1f38848278d07926ed16c2675393e is not yet valid
[    3.118639] MODSIGN: Problem loading in-kernel X.509 certificate (-129)

...and then spew error messages every time a module is loaded. 

For the kernel, it makes *absolutely* no sense to be checking the start
date of the certificate. We do not have a usage model where someone says
"hey, here's this kernel module but I don't want you to be able to use
it until tomorrow so I've post-dated its signature".

If we *ever* try to load a signed kernel module when the certificate is
"not yet valid", it's because the clock is wrong. It's as simple as
that.

And even if we *did* want to support that stupid "load this tomorrow"
use case, it's broken. You couldn't boot today, then load the offending
module tomorrow. You'd have to *reboot* tomorrow, because the kernel
refused to load the damn cert into its store at all.

For the specific case of module signing, we should probably just disable
the date checks completely.

-- 
dwmw2

Attachment: smime.p7s
Description: S/MIME cryptographic signature