Ensure that /etc/cron.allow exists
Ensures /etc/cron.allow exists (owned by root:root, mode 0600) so crontab use is restricted to an explicit allow list.
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
crond decides who may run crontab based on cron.allow/cron.deny. When cron.allow exists, only users listed in it (plus root) can install cron jobs, a default-deny posture. An allow list is safer than a deny list: forgetting to deny a new account silently grants it scheduling, whereas an allow list grants nothing by default. An empty, root-owned cron.allow blocks all non-root crontabs, limiting a foothold an attacker could use for persistence.
What Pavois checks
Pavois verifies the actual file /etc/cron.allow exists on the live system via the InSpec file resource, which queries the real inode rather than a config template. The presence of this file is the effective access-control state crond reads when a user runs crontab.
describe file('/etc/cron.allow') do
it { should exist }
endHow to verify it is applied
Run ls -l /etc/cron.allow and confirm it exists with owner root, group root, mode 0600. Test enforcement by running crontab -e as a non-listed user (it should be refused: You (user) are not allowed to use this program). Re-running the InSpec command should pass.
Inspect & investigate
Inspect the file state with stat /etc/cron.allow. Cron access denials and job activity are logged by the cron service via journalctl -u cron (Debian/Ubuntu) or journalctl -u crond (RHEL family), or in /var/log/cron / /var/log/syslog.
Remediation
pavois harden apply uses the file resource to create /etc/cron.allow as an empty file owned by root:root with mode 0600. An empty allow list means only root may use crontab; add usernames (one per line) afterward to grant specific accounts.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| content | |
|---|---|
| group | crontab |
| mode | 0640 |
| owner | root |
| path | /etc/cron.allow |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Creating an empty cron.allow immediately blocks all non-root users from installing crontabs. Existing crontabs already installed keep running, but affected users can no longer edit them. If legitimate users rely on crontab, add their usernames to the file before or right after applying. No service restart is required; the change takes effect on the next crontab invocation.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.4.1.2, 2.4.1.8, 2.4.1.9 | 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.