Verify Permissions on crontab
Ensures /etc/crontab is owned by root and is not writable or readable by group/other and carries no setuid/setgid/sticky or execute bits, so only root can edit the system crontab.
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/crontab is the system-wide crontab whose entries the cron daemon runs as the user named in each line, typically root. If it is writable by group or other, an attacker can append a line that executes any command as root, direct system compromise. If it is readable by group/other, the schedule and any embedded paths or credentials are exposed for reconnaissance. Restricting it to the owner prevents both unauthorized changes and disclosure.
What Pavois checks
Pavois reads the live inode with file('/etc/crontab') and asserts no group/other read or write, no execute bit, and no setuid/setgid/sticky, 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/crontab').exist? }
describe file('/etc/crontab') do
it { should_not be_executable.by('owner') }
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/crontab. Expected: mode 600 (or stricter), owner root, group root, no read/write for group or other, no execute bit, and no setuid/setgid/sticky bit.
Inspect & investigate
No service log applies; inspect with stat /etc/crontab or ls -l /etc/crontab. To detect tampering, add an auditd watch (auditctl -w /etc/crontab -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/crontab && chmod 600 /etc/crontab. 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 | 0600 |
| owner | root |
| path | /etc/crontab |
| 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 /etc/crontab is a direct root-command-execution and persistence vector; readable, it leaks the schedule and any secrets embedded in job lines. Precautions: restricting to root:root 600 is safe, the cron daemon reads it as root. The change is non-disruptive; just keep ownership root:root so root retains the ability to edit it.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.2 | 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.