4:08 p.m.
https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity
== Summary ==
Support for the Network Time Security (NTS) authentication mechanism
in the NTP client/server (chrony) and installer (anaconda).
== Owner ==
* Name: [[User:mlichvar| Miroslav Lichvar]], [[User:mkolman| Martin Kolman]]
* Email: mlichvar(a)redhat.com, mkolman(a)redhat.com
== Detailed Description ==
NTP is a widely used protocol for synchronization of clocks over
network. Authentication of NTP packets is important to prevent a
Man-in-the-middle (MITM) attacker from taking full control over the
client's clock (e.g. force it to jump to a distant future or past).
Several different authentication mechanisms have been specified for
NTP. The oldest and simplest one uses secret keys, where each client
has its own key which needs to be securely distributed to the server
and client. This means it is mostly limited to local networks. Autokey
is a newer mechanism based on public-key cryptography, but it was
shown to be insecure and it is rarely supported on public servers.
NTS is a new authentication mechanism
[https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp
specified by the IETF] for NTP. NTS has an NTS-KE protocol using
Transport Layer Security (TLS) to establish the keys and provide the
client with cookies which allow the NTP server to not keep any
client-specific state. NTP packets are authenticated using
Authenticated Encryption with Associated Data (AEAD). NTS is expected
to scale well to a large numbers of clients. There are already some
public NTP servers with NTS support.
The default NTP client and server on Fedora is `chrony`. Support for
NTS is added in version 4.0. It uses the GnuTLS library for TLS and
the Nettle library for AEAD.
NTS authentication can be enabled on the client by adding the `nts`
option to the `server` or `pool` directive in ''/etc/chrony.conf''.
Until a standard port is assigned for NTS by IANA, the port may need
to be specified with the `ntsport` option. For example
`
server time.example.com iburst nts ntsport 12123
`
When using NTS-enabled NTP sources, any NTP source that is not trusted
and reachable over a trusted network should be disabled. This includes
servers provided by DHCP. They should be disabled by adding
`PEERNTP=no` to ''/etc/sysconfig/network''.
We can consider changing the default ''/etc/chrony.conf'' to use some
trusted public NTP servers with NTS support. There are public servers
provided by [https://www.cloudflare.com/time/ Cloudflare] and
[https://www.netnod.se/time-and-frequency/how-to-use-nts Netnod]. Both
would be ok with Fedora using their servers by default (after some
testing and coordination). There is also a possibility that
pool.ntp.org will support NTS, although it is not very clear how
useful would NTS be in this case as the servers are owned by
individual contributors instead of a single trusted entity and
attackers can easily join the pool (some mitigations have been
proposed on the pool mailing list).
Potential issues with enabling NTS by default:
* Firewalls may block the NTS-KE port.
* ISPs may block or rate limit longer NTP packets as a mitigation for
amplification attacks using NTP mode 6 and 7. NTS-KE supports port
negotiation and an alternative port could be used to avoid this issue.
* Computers with no RTC (e.g. some ARM boards), or RTC that is too far
from the real time, will fail to verify TLS certificates. An option
could be added to disable the time checks before the first update of
the clock. This would have an impact on security.
== Benefit to Fedora ==
This change enables Fedora users to securely synchronize the system
clock to local or public NTP servers.
TBD: This change also makes the default configuration of the NTP client secure.
== Scope ==
* Proposal owners:
# Update `chrony` to 4.0 and enable the NTS support (adding dependency
on GnuTLS)
# TBD: Modify the default ''/etc/chrony.conf'' to use public servers
with NTS support
# Add an NTS option to the NTP settings in anaconda
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Fedora systems updated from a previous version will use the new
''/etc/chrony.conf'' automatically if the installed file was not
modified. If it was modified, the users will need to update the file
manually or rename ''/etc/chrony.conf.rpmnew'' to
''/etc/chrony.conf'' in order to enable NTS.
== How To Test ==
If the default configuration is modified for this Change, it needs to
be tested that it works correctly on most systems where the previous
default configuration using pool.ntp.org servers worked.
The installer needs to be tested that it enables NTS in
''/etc/chrony.conf'' as expected and that it adds `PEERNTP=no` to
''/etc/sysconfig/network''.
The `chronyc -N sources` command can be used to verify that NTP
sources are responding. The `chronyc ntpdata` command can be used to
verify that the NTP sources are authenticated. For example:
# chronyc -N sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.cloudflare.com 3 6 377 28 -115us[
-111us] +/- 13ms
^+ nts.ntp.se 2 6 377 27 +212us[
+212us] +/- 22ms
# chronyc ntpdata | grep Auth
Authenticated : Yes
Authenticated : Yes
== User Experience ==
Client NTS can be enabled in the NTP settings in the installer.
Client and server NTS can be enabled by editing ''/etc/chrony.conf''
as documented in the `chrony.conf` man page.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product?
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
1:41 p.m.
On 4/6/20 4:08 PM, Ben Cotton wrote:
[snip]
It doesn't make much sense to me for this to default to on if we still
"trust" the DNS servers provided over DHCP. Additionally, it's not clear
to me from the proposal what it would take for an NTP server provided
over DHCP to be "trusted", or what a "trusted network" is. Are only
NTS-enabled sources to be trusted?
What becomes of the old default fedora.pool.ntp.org?
Finally, from a purely personal standpoint, I don't like seeing yet more
infrastructure being handed over to a hyperscaler like Cloudflare (see
also DoH in Firefox). I would be less opposed to this being default if
pool.ntp.org found a way to support it.
3:20 p.m.
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote:
On 4/6/20 4:08 PM, Ben Cotton wrote:
> [snip]
>
>
It doesn't make much sense to me for this to default to on if we still
"trust" the DNS servers provided over DHCP. Additionally, it's not clear
to
me from the proposal what it would take for an NTP server provided over DHCP
to be "trusted", or what a "trusted network" is. Are only
NTS-enabled
sources to be trusted?
What becomes of the old default fedora.pool.ntp.org?
Finally, from a purely personal standpoint, I don't like seeing yet more
infrastructure being handed over to a hyperscaler like Cloudflare (see also
DoH in Firefox). I would be less opposed to this being default if
pool.ntp.org found a way to support it.
I don't know the answers to your questions on the change, but just FYI,
firefox in Fedora is not using DoH.
kevin
3:42 a.m.
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote:
It doesn't make much sense to me for this to default to on if we
still
"trust" the DNS servers provided over DHCP.
What is the issue with using untrusted DNS servers here? An NTS client
is supposed to verify the certificates. Local MITM attackers shouldn't
be able to force the client to synchronize to a different NTP server.
(Of course, they can always disable the synchronization.)
Additionally, it's not clear to
me from the proposal what it would take for an NTP server provided over DHCP
to be "trusted", or what a "trusted network" is. Are only
NTS-enabled
sources to be trusted?
Generally, yes.
What I meant, if someone for example had at home a stratum 1 server
(e.g. synchronized to GPS) and they trusted everything and everyone in
their local network, it would make sense to still use the server
(without NTS) in addition to any external time servers authenticated
by NTS.
The question is if we need to change the default value of the PEERNTP
option. There could be a new default which adds the servers provided
by DHCP only if chronyd is not using any servers with enabled
authentication.
What becomes of the old default fedora.pool.ntp.org?
It would still work, even if we didn't use it by default. The name is
just an alias for pool.ntp.org. The servers used in the current
default configuration are not run by Fedora.
Finally, from a purely personal standpoint, I don't like seeing
yet more
infrastructure being handed over to a hyperscaler like Cloudflare (see also
DoH in Firefox). I would be less opposed to this being default if
pool.ntp.org found a way to support it.
Yes, that's a valid point, which we need to consider. I don't have a
strong opinion either way.
I'd like to see pool.ntp.org to support NTS. But I'm not sure if the
trust of not being attacked will be comparable to a single entity
running the servers, even if the pool has a sufficient number of
NTS-enabled servers and implements some mitigations like mixing
servers from different countries.
--
Miroslav Lichvar
2:09 p.m.
On 4/8/20 3:42 AM, Miroslav Lichvar wrote:
On Tue, Apr 07, 2020 at 01:41:48PM -0500, Brandon Nielsen wrote:
> It doesn't make much sense to me for this to default to on if we still
> "trust" the DNS servers provided over DHCP.
What is the issue with using untrusted DNS servers here? An NTS client
is supposed to verify the certificates. Local MITM attackers shouldn't
be able to force the client to synchronize to a different NTP server.
(Of course, they can always disable the synchronization.)
I'm not saying there is necessarily an issue, just a logical
inconsistency. If the DNS servers provided by DHCP are trusted, why
would any plain NTP servers also provided by DHCP not be trusted? I can
do nefarious things with either.
Generally speaking, on a network I admin, if I've configured DHCP to
provide things like NTP and DNS servers, it's because I intend client
devices to use those things. While some devices choose to ignore DHCP
provided DNS (and NTP), I can still reroute those requests at the edge
router. Is that also possible with NTS? Even if it gets rerouted to a
plain NTP server?
> Additionally, it's not clear to
> me from the proposal what it would take for an NTP server provided over DHCP
> to be "trusted", or what a "trusted network" is. Are only
NTS-enabled
> sources to be trusted?
Generally, yes.
What I meant, if someone for example had at home a stratum 1 server
(e.g. synchronized to GPS) and they trusted everything and everyone in
their local network, it would make sense to still use the server
(without NTS) in addition to any external time servers authenticated
by NTS.
The question is if we need to change the default value of the PEERNTP
option. There could be a new default which adds the servers provided
by DHCP only if chronyd is not using any servers with enabled
authentication.
That makes sense. But again, if I don't trust everything and everyone in
my network, why do I trust the provided DNS servers?
I feel like if this is on by default we're basically saying nobody
trusts any provided NTP server unless it supports NTS. If that's the
case, do away with the 'trusted network' verbiage and just say that only
NTS servers provided over DHCP will be used.
Additionally, what about the no-internet case? Will a local, non-NTS NTP
server be acceptable in that case? I feel like that would be handled by
the change to PEERNTP you mention above. But then can't attackers
"disable the synchronization" as you mention above, essentially forcing
us back to no additional security?
Maybe what we should really have is a REQUIRENTS option for chronyd?
> What becomes of the old default fedora.pool.ntp.org?
It would still work, even if we didn't use it by default. The name is
just an alias for pool.ntp.org. The servers used in the current
default configuration are not run by Fedora.
Does the alias provide no additional functionality? Does it help with an
estimate of running Fedora machines in the wild?
> Finally, from a purely personal standpoint, I don't like
seeing yet more
> infrastructure being handed over to a hyperscaler like Cloudflare (see also
> DoH in Firefox). I would be less opposed to this being default if
> pool.ntp.org found a way to support it.
Yes, that's a valid point, which we need to consider. I don't have a
strong opinion either way.
I'd like to see pool.ntp.org to support NTS. But I'm not sure if the
trust of not being attacked will be comparable to a single entity
running the servers, even if the pool has a sufficient number of
NTS-enabled servers and implements some mitigations like mixing
servers from different countries.
Will there be some kind of 'canary domain' like there is for DoH
(use-application-dns.net)? Again from a network admin standpoint, if I
provide a local NTP server without NTS, I want an easy way to tell the
devices I manage to use it.
From a user standpoint, I like this change and the security it offers.
But with a network admin hat on, it feels like yet more local
infrastructure being pushed outside of my control.
10:42 a.m.
Brandon Nielsen wrote:
If the DNS servers provided by DHCP are trusted, why
would any plain NTP servers also provided by DHCP not be trusted? I can
do nefarious things with either.
For DNS the solution is to not trust the DHCP-provided resolvers but
validate DNSsec locally. A valid chain of DNSsec signatures tells you
that the DNS record is authentic regardless of what servers it passed
through on its way to you. Then you can use a DHCP-provided resolver
without trusting it because the only nefarious thing it can do is to
refuse to resolve a name for you, which just makes it a broken resolver.
A similar approach for NTP would be if the stratum-1 servers would sign
timestamps that secondary servers would cache and forward to clients,
but caching timestamps doesn't work because the nature of a clock is
that the time changes all the time. Thus I don't see how you can get out
of trusting the NTP servers you use.
Fedora's defaults should be chosen to keep users reasonably secure every
way we can. If you as a sysadmin trust the DHCP server and every other
device on the local network – including any device that may be connected
in the future – then you should have the option to configure the system
to trust DHCP-provided NTP and DNS servers.
Björn Persson
2:06 p.m.
On 4/9/20 10:42 AM, Björn Persson wrote:
[snip]
Fedora's defaults should be chosen to keep users reasonably secure every
way we can. If you as a sysadmin trust the DHCP server and every other
device on the local network – including any device that may be connected
in the future – then you should have the option to configure the system
to trust DHCP-provided NTP and DNS servers.
Björn Persson
That's one part of my complaint (which, admittedly, doesn't have much to
do with this proposal). We seem to be trending toward some awkward
one-size-fits-some semi-trust system where parts of the network are
trusted as provided, and other parts aren't.
What I would love to see take shape instead (and again, I acknowledge
this has almost nothing at all to to with this proposal) is the ability
for users to easily mark networks as trusted or untrusted, with trusted
networks using network provided resources, and the system firewall wide
open (the current workstation default). On untrusted networks, DNSSEC /
DoH / DoT (rough order of preference) used for DNS from a trusted
resolver, NTS, firewall locked down, and maybe even a connection to a
VPN automatically established if configured by the user.
11:06 a.m.
On Wed, Apr 08, 2020 at 02:09:01PM -0500, Brandon Nielsen wrote:
On 4/8/20 3:42 AM, Miroslav Lichvar wrote:
> What is the issue with using untrusted DNS servers here? An NTS client
> is supposed to verify the certificates. Local MITM attackers shouldn't
> be able to force the client to synchronize to a different NTP server.
> (Of course, they can always disable the synchronization.)
>
I'm not saying there is necessarily an issue, just a logical inconsistency.
If the DNS servers provided by DHCP are trusted, why would any plain NTP
servers also provided by DHCP not be trusted? I can do nefarious things with
either.
I think it depends on the network. Is it yours or is it a random hotspot?
In general neither should be trusted, but most applications don't rely
on DNS being secure, so using random untrusted DNS servers from DHCP
is usually not a major issue. I'm ignoring privacy issues.
Generally speaking, on a network I admin, if I've configured DHCP
to provide
things like NTP and DNS servers, it's because I intend client devices to use
those things. While some devices choose to ignore DHCP provided DNS (and
NTP), I can still reroute those requests at the edge router. Is that also
possible with NTS? Even if it gets rerouted to a plain NTP server?
No, an NTS-enabled client cannot be redirected to a different server
(using a different certificate or NTS keys). That would be a security
issue. It's similar to DNS over HTTPS.
I feel like if this is on by default we're basically saying
nobody trusts
any provided NTP server unless it supports NTS. If that's the case, do away
with the 'trusted network' verbiage and just say that only NTS servers
provided over DHCP will be used.
The NTP option in DHCP doesn't provide the client with a name of the
server (at least in IPv4), so it couldn't try NTS even if it wanted.
Additionally, what about the no-internet case? Will a local, non-NTS
NTP
server be acceptable in that case? I feel like that would be handled by the
change to PEERNTP you mention above. But then can't attackers "disable the
synchronization" as you mention above, essentially forcing us back to no
additional security?
I think the installer could verify that NTS works (which implies
working Internet connection) and if not, it would leave PEERNTP
enabled.
> It would still work, even if we didn't use it by default.
The name is
> just an alias for pool.ntp.org. The servers used in the current
> default configuration are not run by Fedora.
>
Does the alias provide no additional functionality? Does it help with an
estimate of running Fedora machines in the wild?
The alias is a "vendor" zone to give the pool admins some control in
case our NTP clients create too much traffic and need to be stopped.
I think the admins have some statistics on DNS traffic in specific
zones, but I'm not privy to the data.
Will there be some kind of 'canary domain' like there is for
DoH
(use-application-dns.net)?
I don't think I saw any suggestions for implementing that.
Again from a network admin standpoint, if I
provide a local NTP server without NTS, I want an easy way to tell the
devices I manage to use it.
The PEERNTP option will still work. It may just have a different
default and/or have a new setting.
--
Miroslav Lichvar
2:08 p.m.
On 4/9/20 11:06 AM, Miroslav Lichvar wrote:
On Wed, Apr 08, 2020 at 02:09:01PM -0500, Brandon Nielsen wrote:
> On 4/8/20 3:42 AM, Miroslav Lichvar wrote:
>> What is the issue with using untrusted DNS servers here? An NTS client
>> is supposed to verify the certificates. Local MITM attackers shouldn't
>> be able to force the client to synchronize to a different NTP server.
>> (Of course, they can always disable the synchronization.)
>>
>
> I'm not saying there is necessarily an issue, just a logical inconsistency.
> If the DNS servers provided by DHCP are trusted, why would any plain NTP
> servers also provided by DHCP not be trusted? I can do nefarious things with
> either.
I think it depends on the network. Is it yours or is it a random hotspot?
In general neither should be trusted, but most applications don't rely
on DNS being secure, so using random untrusted DNS servers from DHCP
is usually not a major issue. I'm ignoring privacy issues.
I disagree with saying applications don't rely on DNS being secure, but
I also concede it has very little to do with this discussion. See my
off-topic rant in my reply to Björn Persson. I apologize for conflating
the issue in the first place.
[snip]
The PEERNTP option will still work. It may just have a different
default and/or have a new setting.
Circling back to my concerns about this proposal from an admin
standpoint. I have never needed to touch PEERNTP before for DHCP
provided NTP to work. I'm also not sure from a security standpoint I
want `PEERNTP=yes` to work if NTS is otherwise enabled? Seems
potentially confusing. I don't like chrony behavior being dictated by
non-chrony config.
Additionally, the 'nts' option for 'server' and 'pool' directives,
to
me, does not make it immediately clear that NTS will be required for
_all_ NTP servers. To me, that option implies that NTS will be enforced
for that particular pool or server. Especially since I can have
additional directives without that option set (which admittedly makes
little sense).
Finally, the suggestion of bootstrapping NTP without using NTS when TLS
checks fail concerns me. It needs to be clear when such a thing is
allowed or not.
I would be much happier with some kind of `requireents` option in
`/etc/chrony.conf`. When set, NTS is an absolute hard requirement, no
plain NTP servers will be used (from DHCP or otherwise), NTP
bootstrapping mentioned above would also be forbidden. When not set, NTS
is still verified for cases where the option is set, but other NTP
servers still work (bootstrapping allowed?).
Logging would help make clear what's going on, if the `nts` option is
set on a pool or server with `REQUIREENTS` off, we could log warnings
when non-NTS servers are used. And with `REQUIREENTS` on, we could log
warnings about servers that were ignored due to not supporting NTS
(including the DHCP provided one).
The PEERNTP option would function as usual, not passing DHCP provided
NTP servers to chrony if disabled. It would have no additional influence
over chrony behavior, chrony behavior would remain entirely controlled
by it's own configuration file.
2:51 a.m.
On Thu, Apr 09, 2020 at 02:08:46PM -0500, Brandon Nielsen wrote:
Additionally, the 'nts' option for 'server' and
'pool' directives, to me,
does not make it immediately clear that NTS will be required for _all_ NTP
servers. To me, that option implies that NTS will be enforced for that
particular pool or server. Especially since I can have additional directives
without that option set (which admittedly makes little sense).
Yes, the nts option is specific to the source. Sometimes it makes
sense to mix non-NTS and NTS sources (e.g. in the case with trusted
network), but probably more commonly it does not.
Finally, the suggestion of bootstrapping NTP without using NTS when
TLS
checks fail concerns me. It needs to be clear when such a thing is allowed
or not.
The suggestion was to disable the TLS time check, not TLS+NTS
completely.
I would be much happier with some kind of `requireents` option in
`/etc/chrony.conf`. When set, NTS is an absolute hard requirement, no plain
NTP servers will be used (from DHCP or otherwise), NTP bootstrapping
mentioned above would also be forbidden. When not set, NTS is still verified
for cases where the option is set, but other NTP servers still work
(bootstrapping allowed?).
Good idea. An upstream option to control mixing of authenticated and
non-authenticated sources would make sense to me. This would nicely
minimize downstream-specific changes. I think it might have more than
just two settings (enabled, disabled) and we'll need to figure out
where exactly it should be controlled (e.g. configuration,
measurements, or source selection).
Thanks,
--
Miroslav Lichvar
11:44 a.m.
Hi,
sorry for thread necromancy...
On Wed, Apr 08, 2020 at 10:42:09AM +0200, Miroslav Lichvar wrote:
What I meant, if someone for example had at home a stratum 1 server
(e.g. synchronized to GPS) and they trusted everything and everyone in
their local network, it would make sense to still use the server
(without NTS) in addition to any external time servers authenticated
by NTS.
The question is if we need to change the default value of the PEERNTP
option. There could be a new default which adds the servers provided
by DHCP only if chronyd is not using any servers with enabled
authentication.
Aside: the PEERNTP option seems to be very weakly documented. After
some searching I found [1, 2] and [3]. Some up-to-date documentation would
be necessary if users are expected to configure this.
[1]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
[2]
https://docs.fedoraproject.org/en-US/Fedora/26/html/System_Administrators...
[3] https://bugzilla.redhat.com/show_bug.cgi?id=809367
It sounds like PEERNTP should be a per-interface setting. If I'm
connecting to a trusted network or VPN, I might want to use and trust
the provided NTP servers. If connecting to a public network, don't trust
and use NTS to verify servers.
Also, what software supports /etc/sysconfig/network? I think we currently
have initscripts-network, NetworkManager, systemd-networkd in Fedora.
From the original proposal:
Computers with no RTC (e.g. some ARM boards), or RTC that is too far
from the real time, will fail to verify TLS certificates.
Making NTP not work on boards without RTC could impact a large number
of such users, and also those who have flaky RTCs. Right now they can
simply use NTP to update the clock after boot, and with this proposal
that'd be broken... In my experience, bug reports that stem from broken
RTC are somewhat frequent (e.g. journalctl doesn't handle the case of
a jumping clock very well, and we get reports about this fairly regularly).
So I think handling the no-RTC case gracefully would be a requirement
to make NTS enabled by default.
An option could be added to disable the time checks before the
first update of the clock. This would have an impact on security.
... how would that look? It'd need support in chrony itself, right?
Would upstream accept such code?
Zbyszek
4 a.m.
On Mon, May 04, 2020 at 04:44:00PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Aside: the PEERNTP option seems to be very weakly documented. After
some searching I found [1, 2] and [3]. Some up-to-date documentation would
be necessary if users are expected to configure this.
Ok. I filed bug #1831542 to improve the documentation.
It sounds like PEERNTP should be a per-interface setting. If I'm
connecting to a trusted network or VPN, I might want to use and trust
the provided NTP servers. If connecting to a public network, don't trust
and use NTS to verify servers.
You could do that. PEERNTP can be set for each interface in the
corresponding /etc/sysconfig/network-scripts/ifcfg-* file.
However, as was suggested earlier in the thread, there will likely be
a new upstream option in chrony to globally control mixing of
unauthenticated and authenticated NTP sources, so PEERNTP doesn't have
to be disabled when all NTP servers from DHCP are not to be trusted,
e.g. because they are not expected to authenticate their upstream
servers.
Also, what software supports /etc/sysconfig/network? I think we
currently
have initscripts-network, NetworkManager, systemd-networkd in Fedora.
It works with the initscripts and NetworkManager. For systemd-networkd
there is no dispatcher mechanism in Fedora, so NTP servers provided by
DHCP are ignored when using systemd-networkd with chrony or ntp. In
Debian and Ubuntu there is a networkd-dispatcher service for that.
> An option could be added to disable the time checks before the
> first update of the clock. This would have an impact on security.
... how would that look? It'd need support in chrony itself, right?
Would upstream accept such code?
Yes. It's already supported upstream and in our latest rawhide
package. The time checks can be disabled with the NoCertTimeCheck
directive in chrony.conf. The idea is that anaconda will set it when
no RTC is found or it has no battery backup (if can we detect that).
--
Miroslav Lichvar
1445
days inactive
1474
days old
11 comments
6 participants
participants (6)
-
Ben Cotton -
Björn Persson -
Brandon Nielsen -
Kevin Fenzi -
Miroslav Lichvar -
Zbigniew Jędrzejewski-Szmek