On Mon, 31 Aug 1998, Jeffrey Hutzelman wrote: > > Another, separate problem is the issue of arbitrary drift caused by > > console messages. It is my understanding that some unices turn off all > > interrupts when dumping messages to the console and as such can cause the > > timer to miss a beat. Such is the reason for timed and many other > > collaborative clock management daemons. > > > > I would propose a more subtle mechanism where the system could be told to > > gain or lose a certain number of seconds, but with an inbuilt maximum rate > > of change (say one second every minute). This would allow for gradual > > corrections that are arbitrary on top of a system for guarding against > > constant drift. "I need to make up 13 seconds." -> timetrim( 13 ). > > > > This could all be layered on top of the existing Linux adjtimex however I > > don't know what the limits of it are (i.e. could you make a system gain an > > hour every second). You would also need some method for re-setting the > > time adjustment back to the 'no adjustment' adjustment when the desired > > change has been made. > > Before you reinvent the wheel or try to change any kernel interfaces > related to time synchronization, I'd suggest you take a look at > http://www.eecis.udel.edu/~ntp, which includes a complete description > of the Internet-standard Network Time Protocol and how it works, including > a reference implementation. This is perhaps the single most important > program that actually _uses_ those interfaces, and it uses them to do > fairly complex corrections that allow the time to be readjusted while > still being monotonically increasing. I agree that NTP does a very good job of solving the problem of managing time syncronization. The issue that I was trying to address is the possibility of attacks on a system that are date related. There are the two basic forms of attack; forwards and backwards. Setting the clock back can be used to cover one's tracks from a breakin attempt (trojans, etc.) while both can be used for various DoS attacks against servers. Consider the two examples below: Certain database systems use timestamps in table entries to determine whether or not the row is still valid. A start time and an end time determine whether or not the record is current. The amount of havoc that could be caused by an attacker who either shifts the time backwards, causing new records to be erroneously entered with past 'start' times, as well as shifting the time forwards so that while the time is in the future, records are flagged with end dates in the future. Once the clock is set back records that should have been deleted are now present again. Another attack could be used against systems that use near any form of public key certificates. Set the time forward to a point past the expiration of the certificate and one could cause trouble with someone's web server. Whatever scheme is devised to prevent time attacks must still allow for drift correction via various time control & syncronization mechanisms--such as NTP. Are there any systems that have solved the dual problem of 1) managing drift and lag and 2) preventing an attacker from being able to cause 'time warps' in the system? C=) -------------------------------------------------------------------------- There is hardly a thing in the world that some man can not make a little worse and sell a little cheaper. -------------------------------------------------------------------------- Caskey <caskey*technocage.com> /// pager.818.698.2306 TechnoCage Inc. ///| gpg: 1024D/7BBB1485 -------------------------------------------------------------------------- I didn't fight my way to the top of the food chain to be a vegetarian.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:47 PDT