Verify Owner on cron.d
Ensures the cron drop-in directory /etc/cron.d is owned by the root user (UID 0).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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
The /etc/cron.d directory holds crontab fragments that run as root with a full schedule and user field. If it is not owned by root, an unprivileged user could drop a job file there and have arbitrary commands executed as root at a time of their choosing, a direct path to privilege escalation and persistence. Root ownership of this drop-in directory is essential.
What Pavois checks
Pavois reads the effective owner of /etc/cron.d via the InSpec file resource and asserts uid == 0, only when the directory exists (only_if). Inspecting the live inode ownership reflects the real on-disk state and catches drift from package installs or manual changes, instead of an assumed default.
only_if { file('/etc/cron.d').exist? }
describe file('/etc/cron.d') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/cron.d. Expected output: root 0. Alternatively ls -ld /etc/cron.d should show root in the owner column.
Inspect & investigate
Ownership has no service log. Confirm the state with stat -c '%U %u' /etc/cron.d. To trace changes, an auditd watch such as auditctl -w /etc/cron.d -p wa -k cron-dir records writes/attribute changes in /var/log/audit/audit.log; cron execution is logged via journalctl -u cron (Debian/Ubuntu) or journalctl -u crond (RHEL family).
Remediation
No automated harden plan is defined for this rule, so it must be applied manually: run chown root /etc/cron.d as root to set the owner to root.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /etc/cron.d |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If misconfigured, a non-root user could place a job file that runs arbitrary commands as root, leading to escalation or persistence.
Precautions before applying: chown root /etc/cron.d is safe and reversible with no service restart. Apply to the directory; if you use -R, review existing fragments so you do not re-own files managed by packages.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.7, 2.4.1.8 | direct | per OS, see the benchmark table | high |
| NIST | AC-6(1), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.6 | 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.