From owner-freebsd-hackers Thu Apr 8 3:15: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay04.indigo.ie (relay04.indigo.ie [194.125.133.228]) by hub.freebsd.org (Postfix) with SMTP id B1B581533D for ; Thu, 8 Apr 1999 03:15:01 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 6175 messnum 46437 invoked from network[194.125.205.180/ts08-050.dublin.indigo.ie]); 8 Apr 1999 10:13:01 -0000 Received: from ts08-050.dublin.indigo.ie (HELO pobox.com) (194.125.205.180) by relay04.indigo.ie (qp 6175) with SMTP; 8 Apr 1999 10:13:01 -0000 Message-ID: <370C81CC.A39B1743@pobox.com> Date: Thu, 08 Apr 1999 11:15:40 +0100 From: Niall Smart X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Re: Revised suggestion for securelevel negative time deltas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. Regards, Niall. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message