Verify Permissions on /etc/at.deny file
Ensures /etc/at.deny 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.deny is the deny-list of users forbidden from scheduling at jobs (it is consulted only when at.allow is absent). If it is world-readable or group/other-writable, an unauthorized user could read who is blocked or edit the list to remove their own name, bypassing the restriction and gaining the ability to run scheduled commands. Permissions of 0640 or stricter keep at access policy under root's control.
What Pavois checks
Pavois reads the file's live mode bits through the InSpec file resource, not a package default. Each should_not be_writable/readable/executable/setuid… matcher inspects the actual inode the kernel enforces, catching any permission loosened after install. The only_if { file('/etc/at.deny').exist? } guard skips the check (without failing) when the file is absent.
only_if { file('/etc/at.deny').exist? }
describe file('/etc/at.deny') 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.deny. Expected output is 640 root root /etc/at.deny (or stricter, e.g. 600).
Inspect & investigate
at activity is recorded by journalctl -u atd and in /var/log/syslog. Permission changes on the file can be tracked with an auditd watch: grep at.deny /var/log/audit/audit.log.
Remediation
No automated remediation is defined, so apply it manually: chown root:root /etc/at.deny && chmod 640 /etc/at.deny. Note that CIS hardening usually prefers an explicit at.allow and the removal of at.deny; if you keep at.deny, this rule guarantees it stays protected.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | test -e /etc/at.deny && { chown root:root /etc/at.deny; chmod 0640 /etc/at.deny; }; true |
|---|---|
| name | at-deny-perms |
| not_if | ! test -e /etc/at.deny |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: a writable deny-list can be edited to escape the at restriction. Precautions: tightening these permissions is safe, only root and atd read this file. There is no lockout risk; just verify no non-root tooling parses /etc/at.deny before restricting read access.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.4.2.1 | 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.