Verify Group Who Owns /etc/at.deny file
Ensures /etc/at.deny, the list of users denied use of the at scheduler, is group-owned by root (gid 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 lists the users forbidden from scheduling jobs with at. If its group owner is not root (gid 0), a non-privileged group could edit the file to remove its own entry and regain access to the at scheduler, defeating the deny list.
What Pavois checks
Pavois reads the effective ownership of /etc/at.deny from the inode (via stat) and asserts gid == 0. This reflects the real on-disk state at scan time rather than a configuration template's intent, catching ownership drift from package updates or manual edits. Many hardened systems prefer an allow-list and delete at.deny; the only_if guard skips the check when the file is absent.
only_if { file('/etc/at.deny').exist? }
describe file('/etc/at.deny') do
its('gid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%G %g' /etc/at.deny. Expected output: root 0. If the file does not exist the control is skipped.
Inspect & investigate
Ownership changes are not logged by default. Inspect with ls -l /etc/at.deny or stat /etc/at.deny. With an auditd watch (auditctl -w /etc/at.deny -p wa), chown events surface in /var/log/audit/audit.log.
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: run chgrp root /etc/at.deny (or chown :root /etc/at.deny) to restore the root group owner.
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
A wrong group owner on /etc/at.deny lets an unprivileged group edit the deny list and bypass the restriction. Precautions: restoring the root group is low-risk and does not change who is currently denied; verify no configuration manager will revert it. On allow-list-based setups, consider removing at.deny entirely rather than relying on it.
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.