Ensure that /etc/cron.deny does not exist
Ensures /etc/cron.deny does not exist, so crontab access is governed solely by the allow list (/etc/cron.allow) under a default-deny model.
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
When cron.allow is present, crond ignores cron.deny, but a leftover cron.deny is misleading and becomes a permissive fallback if cron.allow is ever removed. A deny list is inherently risky: any account not explicitly listed is allowed, so a forgotten or newly created user silently gains the ability to schedule jobs. Removing cron.deny forces reliance on the safer allow-list model.
What Pavois checks
Pavois verifies the actual absence of /etc/cron.deny on the live system via the InSpec file resource, which queries the real filesystem rather than any template. This absence is the effective access-control state read by crond.
describe file('/etc/cron.deny') do
it { should_not exist }
endHow to verify it is applied
Run test ! -e /etc/cron.deny && echo absent (expect absent), or ls -l /etc/cron.deny (expect No such file or directory). Re-running the InSpec command should pass.
Inspect & investigate
Confirm the file state with stat /etc/cron.deny (should report the file is missing). Cron access decisions are visible in the cron service logs via journalctl -u cron (Debian/Ubuntu) or journalctl -u crond (RHEL family), or in /var/log/cron / /var/log/syslog.
Remediation
The remediation object is empty, so Pavois does not auto-remediate this rule. Remove the file manually with rm -f /etc/cron.deny, and make sure /etc/cron.allow exists (see file-cron-allow-exists) so access remains controlled.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | delete |
|---|---|
| path | /etc/cron.deny |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Minimal risk if /etc/cron.allow is already in place. Removing cron.deny without an cron.allow could, on some distros, leave cron open to all users, so apply file-cron-allow-exists together with this rule. No service restart needed; the change takes effect on the next crontab invocation.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.1.8, 2.4.1.9 | direct | per OS, see the benchmark table | high |
| 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.