From owner-freebsd-hackers Thu Apr 8 3:48:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id 47A7515296 for ; Thu, 8 Apr 1999 03:48:06 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.3/8.9.3/Netplex) with ESMTP id SAA17649; Thu, 8 Apr 1999 18:45:58 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199904081045.SAA17649@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Niall Smart Cc: hackers@FreeBSD.ORG Subject: Re: Revised suggestion for securelevel negative time deltas In-reply-to: Your message of "Thu, 08 Apr 1999 11:15:40 +0100." <370C81CC.A39B1743@pobox.com> Date: Thu, 08 Apr 1999 18:45:57 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Niall Smart wrote: > > > 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). > > > > The problem is, how do you measure time when the clock is being > > changed a lot? If you limit the change an attacker can make, > > all he has to do is do it a billion times to achieve the same > > end. Clamping the negative adjustment to the maximum time seen -1 sec > > works because time is an increasing function. You can't similarly > > clamp positive excursions quite so easily. > > Every 7 days you store the current timestamp in "timebase", you > can't change the system clock more than +/- kern.maxclockdelta > from this value. IMHO, this is all getting way too convoluted. I think it would be far better to simply set the time at boot with ntpdate, and once the system is running with a raised securelevel, deny settimeofday() entirely and tell xntpd to just use adjtime(2) to speed or slow the clock. If the clock needs a major adjustment for some reason, a reboot is probably the least of your worries. About the only other thing I can think of is to make settimeofday() do an xntpd-like adjtime() over a given interval. That gets complicated too though. (ie: setting the clock backwards 2 seconds is implemented by shortening the clock by 10% of a second for 20 seconds or something like that.) That's a bit hit-and-miss though and would probably not please xntpd. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message