Verify Permissions on cron.daily
Ensures the /etc/cron.daily 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 daily 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.daily holds scripts that the cron daemon runs every day as root. If the directory is writable by group or other, an unauthorized user can drop or alter a script and have it executed with root privileges, full system compromise. If it is merely readable by group/other, attackers can enumerate scheduled jobs to plan an attack. Restricting it to the owner prevents both unauthorized changes and reconnaissance.
What Pavois checks
Pavois reads the live inode with file('/etc/cron.daily') and asserts no group/other access and no special mode bits. The only_if guard skips the test when the path is absent. Reading the effective permissions on disk catches drift introduced by package upgrades, ad-hoc chmod, or restore-from-backup, things a file-template assumption would miss.
only_if { file('/etc/cron.daily').exist? }
describe file('/etc/cron.daily') do
it { should_not be_setuid }
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.daily. 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.daily or ls -ld /etc/cron.daily. To detect tampering, add an auditd watch (auditctl -w /etc/cron.daily -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.daily && chmod 700 /etc/cron.daily. Re-run the scan to confirm the rule passes.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| mode | 0700 |
| owner | root |
| path | /etc/cron.daily |
| resource | directory |
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.daily is a direct root-code-execution and persistence vector; a readable one leaks the schedule. Precautions: restricting this directory to root is safe, the cron daemon runs as root and is unaffected. Just verify that no non-root service legitimately needs to read or write here (uncommon) before tightening, and keep ownership at root:root so root retains full control.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.4 | 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.