Verify User Who Owns /etc/at.deny file
Ensures /etc/at.deny 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.deny is the deny-list controlling who is forbidden from scheduling at jobs. If it is not owned by root (uid 0), an unauthorized user could remove their own entry to gain at access, or read it to learn the scheduling policy. Root ownership keeps the deny-list authoritative and tamper-resistant.
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 live filesystem owner reflects the policy actually enforced now, catching chown drift, instead of trusting a package default.
only_if { file('/etc/at.deny').exist? }
describe file('/etc/at.deny') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U' /etc/at.deny. Expected output: root. Alternatively ls -l /etc/at.deny should show root in the owner column.
Inspect & investigate
Ownership is shown by ls -l /etc/at.deny and stat /etc/at.deny. at activity is logged via journalctl -u atd (or systemctl status atd) and in /var/log/syslog//var/log/cron. If auditd watches /etc/at.deny, 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.deny (commonly paired with chgrp root and chmod 600). Note that hardening guides often recommend removing at.deny entirely in favor of an at.allow allow-list; if you keep it, root must own it.
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
Non-root ownership lets a user edit the deny-list to bypass at restrictions, undermining job-scheduling controls. Restoring root ownership is operationally safe since atd runs as root. Precaution: if the file is absent the check is skipped; deleting at.deny while no at.allow exists makes at available to all users, decide your scheduling policy before changing either file.
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.