Verify Permissions on cron.yearly
Ensures the /etc/cron.yearly directory is owned by root and is not readable, writable or executable by group or other, with no setuid/setgid/sticky bits, so only root can add or change yearly cron scripts.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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.yearly holds scripts the cron daemon runs once a year as root. If the directory is writable by group or other, an unauthorized user can plant or modify a script that runs with root privileges, full compromise. If it is readable by group/other, the jobs can be enumerated for reconnaissance. Restricting it to the owner prevents both unauthorized changes and disclosure.
What Pavois checks
Pavois reads the live inode with file('/etc/cron.yearly') and asserts no group/other access and no special mode bits, gated by only_if to skip when absent. Inspecting effective on-disk permissions catches drift from package upgrades, manual chmod, or backup restores that a config-template assumption would miss.
only_if { file('/etc/cron.yearly').exist? }
describe file('/etc/cron.yearly') do
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_readable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endHow to verify it is applied
Run stat -c '%a %U %G' /etc/cron.yearly. Expected: mode 700 (or stricter), owner root, group root, no read/write/execute for group or other, and no setuid/setgid/sticky bit.
Inspect & investigate
No service log applies; inspect with stat /etc/cron.yearly or ls -ld /etc/cron.yearly. To detect tampering, add an auditd watch (auditctl -w /etc/cron.yearly -p wa -k cron) and grep /var/log/audit/audit.log for key="cron".
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/cron.yearly && chmod 700 /etc/cron.yearly. Re-run the scan to confirm the rule passes.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0700 |
|---|---|
| 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
Risk if left misconfigured: a group/other-writable cron.yearly is a root-code-execution and persistence vector; a readable one leaks the schedule. Precautions: restricting to root:root 700 is safe, the cron daemon runs as root. Confirm no non-root tooling legitimately writes here before tightening, and keep ownership at root:root.
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.