lkml.org 
[lkml]   [2013]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Wrong system clock vs X.509 date specifiers
From
Date
On Tue, 2012-09-25 at 16:30 +0100, Alan Cox wrote:
> On Tue, 25 Sep 2012 16:09:54 +0100
> David Howells <dhowells@redhat.com> 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
[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2013-03-14 15:01    [W:0.090 / U:2.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site