From owner-freebsd-hackers Tue Apr 6 2:50:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay03.indigo.ie (relay03.indigo.ie [194.125.133.227]) by hub.freebsd.org (Postfix) with SMTP id B488314BCF for ; Tue, 6 Apr 1999 02:50:16 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 6105 messnum 46114 invoked from network[194.125.220.32/ts05-022.dublin.indigo.ie]); 6 Apr 1999 09:48:17 -0000 Received: from ts05-022.dublin.indigo.ie (HELO pobox.com) (194.125.220.32) by relay03.indigo.ie (qp 6105) with SMTP; 6 Apr 1999 09:48:17 -0000 Message-ID: <3709D915.E3592B05@pobox.com> Date: Tue, 06 Apr 1999 10:51:17 +0100 From: Niall Smart X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nick Sayer Cc: hackers@freebsd.org Subject: Re: Revised suggestion for securelevel negative time deltas References: <199904060202.TAA31558@medusa.kfu.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Sayer wrote: > > Thanks to Garance A Droshihn for a better idea. > > Attempts to negatively offset the clock are clamped to one second less > than the highest the clock has yet reached. This will allow xntpd > (or a miscreant, alas) to "freeze" the clock in place, but not > go backwards in time beyond a second. > Here is a proposed patch. Note the big blank spot where a proposal > for handling positive deltas should go. :-) Well, how about a sysctl (kern.maxclockdelta) which specifies the maximum amount of seconds that the clock can be brought forward or back in a specified period, say 7 days. This fixes the problem mentioned by Matt Dillon (?) whereby an attacker can wind the clock forward indefinately and overflow a time_t. (Naturally this sysctl would be read-only when securelevel > 1). Regards, Niall > --- kern_time.c.orig Fri Apr 2 13:35:13 1999 > +++ kern_time.c Fri Apr 2 13:34:11 1999 > @@ -77,7 +77,8 @@ > settime(tv) > struct timeval *tv; > { > - struct timeval delta, tv1; > + struct timeval delta, tv1, tv2; > + static struct timeval maxtime; > struct timespec ts; > int s; > > @@ -88,13 +89,30 @@ > > /* > * If the system is secure, we do not allow the time to be > - * set to an earlier value (it may be slowed using adjtime, > - * but not set back). This feature prevent interlopers from > - * setting arbitrary time stamps on files. > + * set to a value earlier than 1 second less than the highest > + * time we have yet seen. The worst a miscreant can do in > + * this circumstance is "freeze" time. He couldn't go > + * back to the past. > */ > - if (delta.tv_sec < 0 && securelevel > 1) { > - splx(s); > - return (EPERM); > + if (securelevel > 1) { > + if (delta.tv_sec < 0 || delta.tv_usec < 0) { > + if ( tv1.tv_sec > maxtime.tv_sec ) > + maxtime=tv1; > + tv2=maxtime; > + timevalsub( &tv2, &tv ); > + if ( tv2.tv_sec < -1 ) { > + tv.tv_sec=maxtime.tv_sec-1; > + } > + } > + else { > + /* XXX > + * We have to figure out how to be secure > + * in this case. Allowing arbitrary > + * positive increases allows a miscreant > + * to simply wrap time around the end > + * of time. > + */ > + } > } > > ts.tv_sec = tv->tv_sec; > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message