Verify Group Who Owns /etc/sudoers.d Directory
Ensures the /etc/sudoers.d directory is group-owned by root.
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
The /etc/sudoers.d directory holds drop-in files that grant sudo privileges. If its group owner is not root, members of that group could drop in a file granting themselves passwordless root access, leading to a full privilege escalation. Controlling the group owner is essential to keep the sudo policy trustworthy.
What Pavois checks
Pavois reads the effective group owner of /etc/sudoers.d from the filesystem (stat), reflecting the real state, including a directory recreated by a package update, rather than a value assumed from documentation. This is the directory sudo actually parses, so its ownership is what matters.
only_if { file('/etc/sudoers.d').exist? }
describe file('/etc/sudoers.d') do
its('group') { should eq 'root' }
endHow to verify it is applied
Run stat -c '%G' /etc/sudoers.d. The expected output is root. Alternatively, ls -ld /etc/sudoers.d should show root in the group column.
Inspect & investigate
Ownership changes are not logged by default. Inspect the state with ls -ld /etc/sudoers.d. Sudo policy usage is logged in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). If auditd watches /etc/sudoers.d, ownership changes appear in /var/log/audit/audit.log.
Remediation
Pavois's harden plan sets the group of the file resource /etc/sudoers.d to root (equivalent to chgrp root /etc/sudoers.d). It is applied with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /etc/sudoers.d |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Setting the group to root is the expected state and has no functional impact on sudo, which runs as root. There is no lockout risk. Before applying, confirm no legitimate non-root tool relies on group access to read drop-in files; such cases are rare and usually misconfigurations themselves.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | 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.