Verify Group Who Owns /etc/at.allow file
Ensures /etc/at.allow, the list of users permitted to use 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.allow decides which users may schedule jobs with at. If its group owner is not root (gid 0), a non-privileged group could add itself to the allow list and gain the ability to run scheduled commands, or read the list of authorized users, information useful to an attacker mapping privileged accounts.
What Pavois checks
Pavois reads the effective ownership of /etc/at.allow as resolved by the kernel and asserts gid == 0. The InSpec file resource queries the inode's actual group id via stat, so it reflects the real on-disk state at scan time, including ownership drift caused by package updates, restore scripts or manual edits, rather than what a configuration template claims.
only_if { file('/etc/at.allow').exist? }
describe file('/etc/at.allow') do
its('group') { should eq 'daemon' }
endHow to verify it is applied
Run stat -c '%G %g' /etc/at.allow. Expected output: root 0. The file may legitimately not exist; if so, the control is skipped (the only_if guard).
Inspect & investigate
Ownership changes are not logged by default. Inspect current state with ls -l /etc/at.allow or stat /etc/at.allow. If auditd watches this path (auditctl -w /etc/at.allow -p wa), chown events appear 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.allow (or chown :root /etc/at.allow) to restore the root group owner.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | daemon |
|---|---|
| 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
A wrong group owner on /etc/at.allow lets an unprivileged group read or alter who may use at, potentially escalating to scheduled command execution. Precautions: changing the group to root is low-risk and does not affect users already listed; verify the file is not intentionally managed by a configuration tool (Ansible/Puppet) that would revert the change, and confirm at is still installed before assuming the file should exist.
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.