Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

SUMMARY (2): Consistent clock drift

Última Actualización: 31 de Enero de 2.000 - Lunes

Resumen de los mensajes intercambiados en la lista de correo de administradores de Solaris, en Noviembre y Diciembre de 1.999. 

Subject: SUMMARY (2): Consistent clock drift
Date: Mon, 13 Dec 1999 18:12:27 +0100
From: Jesus Cea Avion <jcea@argo.es>
Organization: Argo Redes y Servicios Telematicos, S.A. - http://www.argo.es/
To: sun-managers <sun-managers@sunmanagers.ececs.uc.edu>

The original summary was sent more than a month ago, but I'd received several interesting emails:

ORIGINAL SUMMARY:

>>>>>

Thanks to:

"McIntire, John" <john_mcintire@ti.com>
David Mitchell <davem@fdgroup.co.uk>
"DAVID,Anthony" <Anthony.DAVID@dewrsb.gov.au>
Roger Fujii <rmf@lookhere.com>
Jochen Bern <bern@penthesilea.uni-trier.de>
Kevin Sheehan {Consulting Poster Child} <kevin@joltin.com>
Dan Brown <brown@obscure.org>
Pete Alleman <Pete.Alleman@cctechnol.com>

Some people ask me about my security concerns running "xntpd":

> I happen to be setting up xntpd, what are some of the security issues

Simply, xntp is a big server running as root. That's a security issue at its own :-).

I'm thinking about running xntp as a low privileged user, and to use a small SUID root "helper" to set the system clock. Future relases of "xntp" should use a similar approach.

Proposals:

  • Use "date -a" in a cron script.

    Since I have 1.8 seconds daily drift, I'd slowly forward the clock a second every 12 hours. "ntpdate" finetunes the clock every 24 hours.

    Problem: The core problem is not solved.

  • Adjust the clock "physically", touching the harware.

    Problem: Not an option!.

  • Some models have PROM settings to control drift.

    Problem: I can't find any useful in my system. And you have a problem with clock granularity. See last option.

  • Use "xntpd", boy.

    Submillisecond precision, and the daemon can be used as a clock reference to other computers in the network.

    Problem: God dawn!. Yet another process running as root!.

  • Use the "tickadj" program included in "xntpd" package.

    This is the real solution I was searching.

    This program change the system "ticks" increment, to compensate fast or slow hardware clocks. The real solution for anybody with a consistent and large clock drift.

    But my drift is fairly small. My clock "ticks" at 99.9979167Hz, instead of the correct 100.0Hz. The system tick is 10000 microseconds, and the correct value should be 10000.2083367.

    Since "tick" can only be integer... If I use 10001, my clock would drift more than now.

    The solution seems to be to set "tick" to 10001 for 5 hours and to 10000 por 19 hours every day. Cron rules!.

    (10001*5+10000*19)/24 = 10000.20833333333333333333

I'll adopt the last solution, until I drop my concerns about xntp running as root...

>>>>> Original Question <<<<<

I have an Ultra 1 with a consistent system clock drift. That is, the workstation "lose" nearly two second per day. That is, a minute by month.

I'm running ntpdate using cron, each night, and the result is approximately: 

[...]
Oct 24 05:27:01 corinto ntpdate[1132]: adjust time server 150.214.94.5
offset 1.841432 sec
Oct 25 05:27:01 corinto ntpdate[18180]: adjust time server 150.214.94.5
offset 1.782236 sec
[...]

I know that I can run xntp daemon to keep the clock within millisecond error, but I'm not interested in this solution from a security perspective.

Is there any system parameter I can set to specify the clock drift in order to the OS to correct it?. Something like the "/etc/ntp.drift" in xntpd package, but native to OS.

I'm using Solaris 2.5.1. <<<<<

Some additional emails received weeks ago:

Casper Dik <casper@holland.sun.com>

>>>>>

>Some people ask me about my security concerns running "xntpd":
>
>> I happen to be setting up xntpd, what are some of the security issues
>
>Simply, xntp is a big server running as root. That's a security issue
>at its own :-).

One of the biggest problems with using a helper is the extra latency induced; I don't think xntpd will be changed to be more secure because of that; you may lose too much of its precision.

Casper

<<<<<

gabriel rosenkoetter <gr@cs.swarthmore.edu>

>>>>>

If running xntpd as root really bothers you that much, then do it through an ssh tunnel and be happy.

xntpd is very stable in my experience (that is, not very hijackable by a local user), and I've not seen a compromise (with any current version of xntp over the past year) that used the protocol remotely.

Anyway, if it's strictly the local problem, then you should ask yourself why you don't trust your users (I'm presuming this is a company) and why you're so concerned about xntpd's stability. That is, do you have printers? Do you run lpd? It's far easier for me to break lpd than it is for me to break xntpd. There are probably bigger security risks.

If it's the remote that bothers you, find a friendly sys admin somewhere and set up an ssh tunnel with his machine to do your xntping.

~ g r @cs.swarthmore.edu

<<<<<

Pete Alleman <Pete.Alleman@cctechnol.com>

>>>>>

> But my drift is fairly small. My clock "ticks" at 99.9979167Hz,
> instead of the correct 100.0Hz. The system tick is 10000 microseconds,
> and the correct value should be 10000.2083367.
>
> Since "tick" can only be integer... If I use 10001, my clock would
> drift more than now.

The tick value is in nanoseconds. Here is a copy of my /etc/init.d/adjtime script: 

/usr/local/bin/tickadj -t 10000425

Works great.

<<<<<

Pete Alleman <Pete.Alleman@cctechnol.com>

>>>>>

> > The tick value is in nanoseconds.
> [...]
> > /usr/local/bin/tickadj -t 10000425
>
> # tickadj
> KERNEL nsec_per_tick = 10000208 nsec
> KERNEL tick = 10000 usec (from nsec_per_tick kernel variable)
> PRESET tick = 10000 usec
> PRESET tickadj = 5 usec
> dosynctodr is on
> KERNEL hz = 100
> calculated hz = 100.00 Hz
>
> See the first line.
>
> It seems to be *NO* difference at all. My clock still drifts 1.8
> seconds/day.

What version of Solaris are you running? I've used it on Solaris 2.6 and Solaris 7. The tick value did not seem to match my calculations, but I got it working quite well with trial and error.

<<<<< 

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

Python Zope ©2000 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS