Record Attempts to Alter Time Through clock_settime
Enforces an auditd rule (key time-change) that records attempts to set the system clock via the clock_settime syscall.
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.
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
Arbitrary changes to the system clock can be used to obfuscate nefarious activity in log files (by skewing timestamps) and to confuse services that depend on accurate time, such as sshd, Kerberos and TLS certificate validation. The clock_settime syscall is one way to set the time directly, so every such call should be audited. A reliable, accurate timeline is the backbone of incident investigation.
What Pavois checks
Pavois runs auditctl -l and checks a rule with the key time-change is loaded. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule on disk that was never loaded (no augenrules --load, syntax error, reload failure) would make a file scanner falsely pass. auditctl -l reflects what the kernel audits now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)time\-change\b/) }
end
describe command("grep -rhwsE 'time\-change' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run auditctl -l | grep -E '(-k |key=)time-change' (as root). Expected output includes the clock_settime syscall rules, for example:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -k time-change-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -k time-change
No output means the rules are not loaded.
Inspect & investigate
Events go to /var/log/audit/audit.log. After a time change, find the record with grep 'key="time-change"' /var/log/audit/audit.log (grep the raw log; ausearch can falsely report no matches). The record shows the auid, the syscall and the timestamp.
Remediation
pavois harden apply uses the audit_ruleset resource to add the missing time-change syscall rules to a Pavois-managed drop-in in /etc/audit/rules.d/ and load them. Because the audit subsystem is locked once running, the change is fully effective only after a reboot (reboot_required: true).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
This is a passive syscall watch, it never blocks time changes, so NTP/chrony and manual date/timedatectl keep working; it only adds records to /var/log/audit/audit.log. Precautions:
- A correctly running NTP daemon disciplines the clock gradually (via
adjtimex) rather than callingclock_settime, so steady-state audit volume from this rule is low. - If the ruleset is immutable (
-e 2), the rule can only be added after a reboot. - Confirm the rule parsed with
augenrules --loadand re-checkauditctl -l.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 10.6.3, 6.2.3.4, 6.3.3.4 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.7, AC-6(9), AU-12(c), AU-2(d), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.6.3 | supporting | 4.0.1 | medium |
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.