Verify User Who Owns /etc/cron.allow file
Ensures the cron allow-list /etc/cron.allow 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.allow file defines which users are permitted to schedule cron jobs. If it is not owned by root, an unauthorized user could add their own name to gain cron access, and thus a foothold for scheduled persistence or privilege escalation, or read it to learn which accounts have cron rights. Controlling ownership keeps the allow-list authoritative.
What Pavois checks
Pavois reads the effective owner of /etc/cron.allow via the InSpec file resource and asserts uid == 0, only when the file exists (only_if). Reading the live inode ownership reflects the actual on-disk state, catching drift from manual edits or administrative scripts rather than relying on an assumed default.
only_if { file('/etc/cron.allow').exist? }
describe file('/etc/cron.allow') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /etc/cron.allow. Expected output: root 0. Alternatively ls -l /etc/cron.allow should show root in the owner column.
Inspect & investigate
Ownership has no service log. Confirm the state with stat -c '%U %u' /etc/cron.allow. To trace changes, an auditd watch such as auditctl -w /etc/cron.allow -p wa -k cron-access records writes/attribute changes in /var/log/audit/audit.log.
Remediation
No automated harden plan is defined for this rule, so it must be applied manually: run chown root /etc/cron.allow 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.allow |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If misconfigured, an unauthorized user could add themselves to the cron allow-list and run scheduled jobs, enabling persistence or escalation.
Precautions before applying: chown root /etc/cron.allow is safe and reversible with no service restart. Note that the mere presence of cron.allow overrides cron.deny; do not create the file as a side effect of remediation, only change ownership if it already exists, or you may unintentionally restrict cron to listed users.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.8, 2.4.1.9 | 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.