Verify Permissions on /etc/at.allow file
Ensures /etc/at.allow is not writable/readable by other or writable by group, and carries no executable or special (setuid/setgid/sticky) bits, i.e. mode 0640 or stricter.
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/at.allow is the allow-list deciding which users may schedule at jobs. If it is world-readable or group/other-writable, an unauthorized user could read who is permitted or, worse, edit the list to grant themselves the ability to run scheduled commands, a foothold for privilege escalation and persistence. Permissions of 0640 or more restrictive keep the control of at access in the hands of root.
What Pavois checks
Pavois queries the file's live mode bits through the InSpec file resource rather than assuming the package default. Each should_not be_writable/readable/executable/setuid… matcher inspects the actual inode the kernel enforces, so a permission loosened after install, by a script, a careless chmod, or a restored backup, is caught. The control is wrapped in only_if { file('/etc/at.allow').exist? } so it is skipped (not failed) when at is not configured.
only_if { file('/etc/at.allow').exist? }
describe file('/etc/at.allow') 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_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 %n' /etc/at.allow. Expected output is 640 root root /etc/at.allow (or stricter, e.g. 600).
Inspect & investigate
Use of at is recorded by journalctl -u atd and in /var/log/syslog (Debian/Ubuntu) or /var/log/cron (RHEL family). Permission changes on the file can be tracked with an auditd watch: grep at.allow /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/at.allow && chmod u-x,g-wx,o-rwx,a-st /etc/at.allow (a clean chmod 640 /etc/at.allow achieves the same target mode).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0600 |
|---|---|
| path | /etc/at.allow |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: leaked or tampered at authorization can let an unauthorized user schedule commands. Precautions: tightening these permissions is safe, only root and the atd service need to read this file, and neither relies on group/other access. Confirm beforehand that no non-root automation reads /etc/at.allow directly (rare); if it does, grant it via the file's group rather than world-readable bits before applying.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 2.4.2.1 | 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.