Verify User Who Owns /etc/at.allow file
Ensures /etc/at.allow is owned by root (uid 0).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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 controlling who may schedule at jobs. If it is not owned by root (uid 0), an unauthorized user could edit it to grant themselves at access, a path to scheduled, privileged command execution, or read it to learn which accounts are trusted. Ownership by root is required to keep job-scheduling policy authoritative.
What Pavois checks
Pavois reads the file's effective owning uid with the InSpec file resource and asserts it equals 0 (root), only when the file exists. Reading the actual filesystem owner reflects the policy currently enforced, catching any chown drift, rather than trusting a package default that may have been changed.
only_if { file('/etc/at.allow').exist? }
describe file('/etc/at.allow') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U' /etc/at.allow. Expected output: root. Alternatively ls -l /etc/at.allow should show root in the owner column.
Inspect & investigate
Ownership is shown by ls -l /etc/at.allow and stat /etc/at.allow. at job activity is logged via journalctl -u atd (or systemctl status atd) and in /var/log/syslog//var/log/cron. If auditd watches /etc/at.allow, chown and write events appear in /var/log/audit/audit.log.
Remediation
No automated harden plan is shipped for this rule, so it must be remediated manually: run chown root /etc/at.allow (commonly paired with chgrp root and chmod 600). The file may not exist by default, create it only if you intend to use an at allow-list.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| 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
Non-root ownership lets an attacker edit the allow-list to gain at scheduling, enabling persistence or privilege escalation. Restoring root ownership has no operational downside, atd runs as root. Precaution: if the file is absent the check is skipped; do not create an empty /etc/at.allow casually, since an empty allow-list denies at to everyone except root and can disrupt legitimate scheduled jobs.
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.