A time-synchronization service is active
Ensures at least one time-synchronization daemon (chrony, chronyd, systemd-timesyncd, ntp or ntpsec) is active so the system clock stays accurate.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
This domain is thinly covered by Pavois today, see coverage.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
Accurate, synchronized clocks are a prerequisite for trustworthy security. Without time sync, log timestamps drift across hosts, making incident correlation and forensics unreliable; TLS/Kerberos authentication breaks (certificate validity windows, ticket lifetimes); scheduled jobs and certificate renewals fire at the wrong time; and PCI-DSS / ANSSI auditing requirements that depend on a common time reference cannot be met.
What Pavois checks
Pavois asks systemd for the live unit state with systemctl is-active, iterating over every known time daemon and passing if any one is running. This audits the effective service status, not the presence of a config file or an installed package: a daemon can be installed and configured yet masked, failed or simply stopped. Only is-active reflects whether the clock is actually being disciplined right now.
describe command('for s in chrony chronyd systemd-timesyncd ntp ntpsec; do systemctl is-active --quiet "$s" && { echo ok; exit 0; }; done; echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Check the running daemon, e.g. systemctl is-active chrony (expected active), and confirm it is actually tracking a source:
# chrony
chronyc tracking
# systemd-timesyncd
timedatectl status # "System clock synchronized: yes"
Inspect & investigate
Use systemctl show <unit> for the unit state and journalctl -u chrony (or -u systemd-timesyncd) for sync events, source selection and step/slew messages. timedatectl status summarizes whether the clock is synchronized and which service is in charge; chronyc sources -v lists upstream peers and their reachability.
Remediation
The harden plan uses a choose resource: by default it installs and enables chrony (package chrony, service chrony), with timesyncd (systemd-timesyncd) as an alternative. pavois harden apply installs the chosen package and activates its service so a synchronization daemon is running. Pick timesyncd on minimal/container-adjacent hosts where chrony is undesirable.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| default | chrony |
|---|---|
| options | chrony: package: chrony, service: chrony.service, timesyncd: package: systemd-timesyncd, service: systemd-timesyncd |
| resource | choose |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Enabling a time daemon is low-risk. Two cautions: (1) only one daemon may discipline the clock - chrony, ntp/ntpsec and systemd-timesyncd conflict, so enabling chrony should be paired with disabling/masking timesyncd to avoid them fighting over the clock; (2) on first sync a large offset can cause a clock step (a sudden jump), which can confuse long-running jobs, databases or TLS sessions - on sensitive hosts prefer slewing (chrony's default) and ensure the host can reach its NTP servers (outbound UDP/123) before relying on it. Inside containers that share the host clock, no in-container daemon is needed.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R71 | direct | 2.0 | high |
| CIS | 2.3.1.1, 2.3.2, 2.3.1 | direct | per OS, see the benchmark table | high |
| NIST | 3.3.7, SC-45 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.6.1 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-215020, UBTU-24-100010 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.