Verify Group Who Owns cron.yearly
Ensures the /etc/cron.yearly directory 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
The /etc/cron.yearly directory holds scripts that the cron daemon runs as root once a year. If it is group-owned by a non-privileged group, a member of that group could drop in or modify a script and gain arbitrary command execution as root. Restricting group ownership to root (gid 0) ensures only highly-privileged accounts can change what runs yearly.
What Pavois checks
Pavois reads the effective group owner of /etc/cron.yearly on the live system via the InSpec file resource and asserts gid == 0. It inspects the actual inode metadata as the kernel sees it, not a packaging default, so a directory whose ownership drifted after install is caught.
only_if { file('/etc/cron.yearly').exist? }
describe file('/etc/cron.yearly') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%G %g' /etc/cron.yearly. Expected output: root 0. Any other group name or non-zero gid means the rule is not applied.
Inspect & investigate
Ownership changes are not logged by default. Watch the directory with auditd: auditctl -w /etc/cron.yearly -p wa -k cron-perms, then inspect grep 'key="cron-perms"' /var/log/audit/audit.log. Yearly job runs appear in journalctl -u crond (RHEL family).
Remediation
No automated remediation is defined for this rule, so it must be applied manually. Restore the correct group ownership with chgrp root /etc/cron.yearly.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /etc/cron.yearly |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root group owner on /etc/cron.yearly lets group members plant root-run scripts, a direct privilege-escalation path. The fix is low-risk: chgrp root only changes group ownership, not permissions or content, and cron keeps working. Precaution: confirm no legitimate tooling relies on a custom group on this directory before changing it.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.4.1.7 | direct | per OS, see the benchmark table | high |
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.