[arch-general] Leap seconds ntp and chrony?

[Leonid Isaev]

On Tue, 3 Jul 2012 17:32:40 +0100
Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:

> 
> Watches are perfectly acceptable time keepers especially considering I
> have a cheap watch stuffed in a drawer that I was surprised hasn't lost
> seconds in years. RTC: I'm fairly sure many older ones don't even have
> crystals but are probably still good enough, though I have no
> accurate quantification yet.

Noone cares about seconds -- we talk about a 10ns resolution. This is cool,
especially if you consider the time scale on which the current propagates
inside your motherboard.

> 
> 
> > Like everything else ntpd has to be properly secured and configured, if
> > properly done I suppose it isn't a bigger security problem than anything
> > else with network access. This problem about the leap second and
> > programs going awry is due to a bug in the kernel and not a problem with
> > ntp itself, the only fault that can be attributed to ntp is to expose
> > that bug.
> 
> Attacker controlled or influenced time is actually more serious than
> you would think for crypto, logging etc., which is why OpenBSD put so
> much effort into it and don't allow the clock to go backwards. So do the
> benefits of ntp outweigh the risk. I'm simply saying in most scenarios
> no.

While I respect OpenBSD, sometimes I think they create too much buzz around
their "security". I have never seen a clear case when OpenNTPD was a winner
security-wise (i.e. not after a default installation).

Are you telling me that if my clock is in the future, openntpd is not going
to adjust it backwards? This certainly happened to me across DST when my clock
was on localtime. NTPD also does this, see man ntpd.

As with any networking protocol, any NTPD implementation opens you to yet
another attack vector -- yes. However, there are also countermeasures, see
http://www.eecis.udel.edu/~mills/security.html.

Have you seen the movie Entrapment
(http://en.wikipedia.org/wiki/Entrapment_(film))? This is roughly how attacks
over NTP can be carried out...

> 
> I'm not saying ntp is at fault, however manually setting the date fixes
> this problem. So the easiest and in my opinion best solution for
> most users that wasn't put forward for most users is to disable ntp and
> set the clock to mr atomic.
> 

Again, RTCs are usually crap -- by design. My understanding that it's not the
drift which troubles, it's the unpredictibility which renders them useless for
event coordination. So if you want good timing you'll have to use ntpd because
OpenNTPD is less accurate, has fewer features and is long unsupported on Linux.

> 



-- 
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20120703/ddc32d86/attachment.asc>