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
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:34 CDT