Ensure auditd Collects Changes to Cron Jobs - /etc/cron.d/
Adds an audit watch on /etc/cron.d/ (key cronjobs) so any change to scheduled jobs in that directory is recorded.
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
/etc/cron.d/ is a classic persistence and privilege-escalation foothold: an attacker who drops or edits a file there can schedule arbitrary commands as root. Auditing changes to this directory keeps an accountable record of every modification, supporting both incident detection and forensic investigation. Without the watch, a malicious cron entry can be added and removed with no trace.
What Pavois checks
Pavois runs auditctl -l, the effective, loaded audit ruleset of the running kernel, and requires a rule keyed cronjobs watching /etc/cron.d/. Reading the live ruleset, not /etc/audit/rules.d/*.rules, is what makes this reliable: a rule sitting in a file but never loaded (no augenrules --load, or a syntax error) would falsely pass a file-based scan but correctly fail here.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)cronjobs\b/) }
end
describe command("grep -rhwsE 'cronjobs' /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 cronjobs. Expected output: a watch line such as -w /etc/cron.d/ -p wa -k cronjobs.
Inspect & investigate
Changes to /etc/cron.d/ are recorded in /var/log/audit/audit.log tagged key="cronjobs". Grep the raw log directly (grep 'key="cronjobs"' /var/log/audit/audit.log) rather than relying on ausearch -k cronjobs, which can falsely report no matches.
Remediation
Pavois's harden plan uses the audit_ruleset resource to add the /etc/cron.d/ watch (key cronjobs) to the persistent audit rules and load it into the kernel; reboot_required is flagged because audit rules become fully immutable and authoritative only after a reboot (the -e 2 enable flag). Apply it with pavois harden apply.
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
A directory watch is low-risk and adds negligible noise (cron files change rarely). The main consideration is the reboot: if the audit configuration is locked immutable (-e 2), further rule changes need a reboot to take effect. Precaution: load the rule with augenrules --load to apply it immediately, and schedule the reboot for the immutable flag during a maintenance window. Verify the rule shows in auditctl -l after loading so coverage is genuinely active.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| DISA STIG | UBTU-22-654041, UBTU-24-200270 | 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.