Record attempts to alter time through adjtimex
Enforces an auditd rule (key audit_time_rules) that records attempts to adjust the system clock via the adjtimex 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 adjtimex syscall tunes the kernel clock and is the path NTP daemons use to slew time, 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 audit_time_rules 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=)audit_time_rules\b/) }
end
describe command("grep -rhwsE 'audit_time_rules' /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=)audit_time_rules' (as root). Expected output includes the adjtimex syscall rules, for example:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -k audit_time_rules-a always,exit -F arch=b32 -S adjtimex,settimeofday -k audit_time_rules
No output means the rules are not loaded.
Inspect & investigate
Events go to /var/log/audit/audit.log. After a time adjustment, find the record with grep 'key="audit_time_rules"' /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 audit_time_rules 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 adjustments, so NTP/chrony and manual date/timedatectl keep working; it only adds records to /var/log/audit/audit.log. Precautions:
- An NTP daemon disciplines the clock by calling
adjtimexperiodically, so this rule can fire regularly on a normally running host, keep an eye on audit volume and ensure/var/log/audithas space and rotation. - 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.