Verify Group Who Owns /etc/cron.allow file
Ensures /etc/cron.allow, the list of users permitted to use cron, is group-owned by root (gid 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
/etc/cron.allow decides which users may create cron jobs. If its group owner is not root (gid 0), a non-privileged group could add itself to the allow list and schedule recurring commands, or read the list of authorized users. Because cron jobs run unattended, this is a common persistence and privilege-escalation vector.
What Pavois checks
Pavois reads the effective ownership of /etc/cron.allow from the inode (via stat) and asserts gid == 0. Checking the live inode catches drift from package updates or manual edits rather than trusting a template. The only_if guard skips the check when the file is absent (some systems rely solely on cron.deny).
only_if { file('/etc/cron.allow').exist? }
describe file('/etc/cron.allow') do
its('group') { should eq 'crontab' }
endHow to verify it is applied
Run stat -c '%G %g' /etc/cron.allow. Expected output: root 0. If the file does not exist the control is skipped.
Inspect & investigate
Ownership changes are not logged by default. Inspect with ls -l /etc/cron.allow or stat /etc/cron.allow. With an auditd watch (auditctl -w /etc/cron.allow -p wa), chown events appear in /var/log/audit/audit.log. Cron job execution is logged in /var/log/syslog / journalctl -u cron (Debian) or journalctl -u crond (RHEL).
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: run chgrp root /etc/cron.allow (or chown :root /etc/cron.allow) to restore the root group owner.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | crontab |
|---|---|
| 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
A wrong group owner on /etc/cron.allow lets an unprivileged group grant itself cron access, a path to persistence and privilege escalation. Precautions: restoring root group ownership is low-risk and does not change who is currently authorized; verify no configuration manager will revert it, and remember that the presence of cron.allow makes cron deny-by-default, confirm all legitimate cron users are listed before relying on it.
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.