Re: Chrony and NTP hardening (fwd)B

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--173737085848839432317702260983718490
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Harden against what? An external adversary (ie one who ccan capture one or =
two
external servers an internal one, who could change that that internal file?
The lattr is of course much harder to protect against. Note that chrony
already can use internal files to set the intial times of chrony as I recal=
l
(for example looking at the timstamps of its log files) Note that an intern=
al
enemy could alter those. Note also that I would not call guarding against a
many many month or year problem. Why would an adversary do that?
Externally, it would seem that using many independent  servers would be the=
 best defence
(which chrony and nptd alredy allow. Of course many do not make sure that t=
he
servers are independent-- eg, all depend on one single root server).



William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-327=
3
Physics&Astronomy _|__ Research Prof, IQSE         |__  US +1(979)7399950
UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr  |_ [email protected]
Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843  _|_www.theory.physics.ubc=
=2Eca
I cannot reply to emails from outlook or hotmail or other microsoft domains=
=2E

---------- Forwarded message ----------
Date: Wed, 4 Feb 2026 08:25:26
From: Holger Hoffst=C3=A4tte <[email protected]>
To: Bernd Brandstetter <kde-bbrand-CB8Jegt/[email protected]>,
     "[email protected]" <[email protected]=
>
Subject: Re: [chrony-users] Chrony and NTP hardening

[CAUTION: Non-UBC Email]

On 2026-02-04 16:57, Bernd Brandstetter wrote:
> Hello,
>=20
> I'm supposed to implement a couple of NTP security requirements as
> suggested by RFC8633.
>=20
> Specifically, the NTP daemon shall be prevented from accepting dates
> that set the clock to a time earlier than the build date of the
> system or a last-known-good time, which will be saved to a file once
> a day.
>=20
> I'm wondering how this could best be achieved with Chrony. My main
> problem is that I can see no way to reliably detect if the time is
> acceptable before Chrony has already synchronized. Moreover, since we
> would also like to use rtcsync, this would mean that then also the
> RTC could be set to the wrong time and we'd therefore have no means
> to recover, and activating rtcsync only afterwards is unfortunately
> not supported.

It's not clear to me whether you want to do this only at startup or
continously at runtime. For the former you will have to write your own
pre-start script where you can check for "the current offset" without
setting the clock with:

   chronyd -x -Q 2>&1 | grep "System clock" | cut -d ' ' -f 6

which will give you something like:

   -0.000211

You can then compare this with the checkpoint time and do whatever is
necessary. Does that help?

cheers
Holger

--=20
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with
"unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in the
subject.
Trouble?  Email [email protected]

--173737085848839432317702260983718490--

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]