Verify Owner on cron.weekly
Ensures the /etc/cron.weekly directory 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.weekly directory holds scripts that cron runs as root once a week. If it is not owned by root, an unprivileged user who can write to it can drop or alter a script and have it executed with full root privileges, a direct privilege-escalation path. Restricting ownership to root ensures only the administrator controls scheduled weekly tasks.
What Pavois checks
Pavois stats the live inode of /etc/cron.weekly and asserts its owner is UID 0. The check is skipped if the directory does not exist. Reading the actual filesystem metadata (not a config file) reflects the effective ownership cron will honor at runtime, including any changes a package or admin made after install.
only_if { file('/etc/cron.weekly').exist? }
describe file('/etc/cron.weekly') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/cron.weekly. The expected output is root 0.
Inspect & investigate
Cron execution is recorded in /var/log/cron (RHEL family) or /var/log/syslog and journalctl -u cron (Debian/Ubuntu). Ownership changes can be tracked with auditd if a watch is set: auditctl -w /etc/cron.weekly -p wa.
Remediation
No automated harden plan is defined for this rule yet, so it must be fixed manually: run chown root /etc/cron.weekly to restore root ownership.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /etc/cron.weekly |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If the directory is owned by a non-root user, that user can schedule arbitrary root-level commands, leading to full system compromise. Fixing it is low-risk: chown root /etc/cron.weekly only changes the owner, not the scripts or their schedule. Verify no legitimate automation relies on a non-root owner before applying, almost never the case for system cron directories.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.5 | 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.