Re: Security Hole in Axent ESM

[jhutz+ () cmu edu (Jeffrey Hutzelman)]

> 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.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ () cmu edu>
   Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA