Date: Tue, 15 Jan 2002 12:56:58 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: FreeBSD@jovi.net Cc: cjc@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: kern/33904: secure mode bug Message-ID: <3C44979A.63F600B0@mindspring.com> References: <200201142344.g0ENimK91227@freefall.freebsd.org> <20020115011230.D28767@blossom.cjclark.org> <200201151526.g0FFQFX02180@grant.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD@jovi.net wrote: > Thanks for your reply. > I suggest escalating the trouble. > Correct time is mission-critical on many systems Agreed. > and this is an issue of unreliable service under FreeBSD. Disagree: FreeBSD is ensuring the correctness of the time by disallowing a delta which is so large as to be useful to someone attempting to hack date stamps on files. If you want to "reliably" change the time by a large delta, then there are only three valid circumstances in which this should be done: 1) Initial installation of a system (in which case you have control over it to the level of being able to not set the secure mode up before you have made the adjustment). 2) You are the Pope, and you are changing the calendar again (I'd be happy to fix it for you, your eminence, particularly if I can let it be known you use FreeBSD). 3) You just got back from a relatavistic flight that resulted in the on board computer in your space ship (I will fix it for free for you, if I am allowed to do it on site, and take the vehicle out for a spin afterwards, to verify that the large delats are now allowed, when necessary). > A settimeofday other than that programmed is worse than doing nothing. Particularly if you are trying to hack someone... > Three orders of magnitude is a complete failure by every reasonable > standard. Breaking date, ntpdate, ntpd, ... is a reliable indication > of severe failure. These programs now need rewriting to operate reliably. I guess you've never used NTP when the drift exceeds an hour or so, without having intentially set your security mode to disable changes over one second? The change is refused if the delta exceeds a maximum delta time, as being "unreasonable" by the NTP code itself, and you have to manually synchronize the clock to get it "in the neighborhood" in the first place before it will start working again. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C44979A.63F600B0>