[arch-general] Leap seconds ntp and chrony?

[Kevin Chadwick]

> > 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.  
> 
> Are you claiming that the security problem of ntp is that it might cause
> time to jump backwards?
> 

I think I've been quite clear, similar to negative coding.

OpenBSD has a security measure called securelevel which if raised from
one to two prevents even root setting the clock backwards or near
overflow as this can have consequences for the entropy pool. They also
put in place measures to reduce client time leakage. The obvious point
I ignored is network exploits as clock adjustment is a root process,
which is why OpenBSDs implements priviledge seperation and chroot.

http://www.openbsd.org/papers/ntpd_sucon04/index.html


> In that case we are lucky, because that's not how it works. Unless you
> specifically tell it to, the time will still be monotone and (almost)
> continuous while adjusted by ntp on Linux.
> 
> I suggest checking how things work before worrying about imaginary security
> threats. Also, read up on the drift rates of RTCs, they are generally
> really bad.

Explain why that matters for the usual case which is logging. I have
servers some offline from which I can cross reference the logs. Do
you... can you.. would you check your logs to the nanosecond and who
said I worried. requirements, benefits and threats.

Quas dederis solas semper habebis opes.

-- 
________________________________________________________

 Why not do something good every day and install BOINC.
________________________________________________________