Verify Group Who Owns cron.deny
Ensures /etc/cron.deny, the list of users denied use of cron, is group-owned by root (gid 0).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
Why this rule matters
/etc/cron.deny lists the users forbidden from creating cron jobs. If its group owner is not root (gid 0), a non-privileged group could edit the file to remove its own entry and regain cron access, defeating the deny list. Because cron jobs run unattended, this enables persistence and privilege escalation.
What Pavois checks
Pavois reads the effective ownership of /etc/cron.deny 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 (hardened systems often use cron.allow instead and delete cron.deny).
only_if { file('/etc/cron.deny').exist? }
describe file('/etc/cron.deny') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%G %g' /etc/cron.deny. 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.deny or stat /etc/cron.deny. With an auditd watch (auditctl -w /etc/cron.deny -p wa), chown events appear in /var/log/audit/audit.log. Cron job execution is visible in journalctl -u crond on RHEL 9.
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: run chgrp root /etc/cron.deny (or chown :root /etc/cron.deny) to restore the root group owner.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /etc/cron.deny |
| 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.deny lets an unprivileged group edit the deny list and regain cron access, a path to persistence and privilege escalation. Precautions: restoring root group ownership is low-risk and does not change who is currently denied. Verify no configuration manager will revert it. Note that cron.allow, when present, takes precedence over cron.deny; prefer an allow-list model for stronger control.