Verify Owner on crontab
Ensures the system crontab /etc/crontab 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/crontab file is the system-wide cron table, whose entries run as the user named in each line, typically root. If it is not owned by root, an unprivileged user could add or modify entries to execute arbitrary commands as root on a schedule, a direct path to privilege escalation and persistence. Root ownership keeps the system crontab trustworthy.
What Pavois checks
Pavois reads the effective owner of /etc/crontab via the InSpec file resource and asserts uid == 0, only when the file exists (only_if). Inspecting the live inode ownership reflects the real on-disk state and catches drift from manual edits or migration tools, instead of an assumed default.
only_if { file('/etc/crontab').exist? }
describe file('/etc/crontab') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/crontab. Expected output: root 0. Alternatively ls -l /etc/crontab should show root in the owner column.
Inspect & investigate
Ownership has no service log. Confirm the state with stat -c '%U %u' /etc/crontab. To trace changes, an auditd watch such as auditctl -w /etc/crontab -p wa -k cron-tab 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/crontab 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/crontab |
| 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 add system crontab entries that run as root, leading to escalation or persistence.
Precautions before applying: chown root /etc/crontab is safe and reversible with no service restart. The change only affects ownership, not the scheduled entries themselves, so no job will stop running and there is no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.2 | 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.