Verify Group Who Owns /etc/sudoers File
Ensures the sudo policy file /etc/sudoers is owned by group 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
/etc/sudoers defines who can run commands as root via sudo. If a non-privileged group owns it, a member of that group could be granted write access and grant themselves (or anyone) full root privileges, a direct privilege-escalation path. Group ownership by root keeps exclusive control of the sudo policy in trusted hands.
What Pavois checks
Pavois reads the real owning group of /etc/sudoers via InSpec's file resource and asserts group == 'root'. It inspects the effective filesystem ownership applied right now, so an accidental chgrp or a tampered /etc/sudoers is detected regardless of what any deployment template claims.
only_if { file('/etc/sudoers').exist? }
describe file('/etc/sudoers') do
its('group') { should eq 'root' }
endHow to verify it is applied
Run stat -c '%G' /etc/sudoers. Expected output: root. (Validate syntax separately with visudo -c.)
Inspect & investigate
Watch it with auditd, auditctl -w /etc/sudoers -p wa -k scope, and ownership or content changes show up in /var/log/audit/audit.log (grep 'key="scope"' /var/log/audit/audit.log). Successful sudo invocations are also logged to /var/log/auth.log (Debian/Ubuntu) or journalctl -t sudo.
Remediation
Pavois's harden plan uses the file resource to set the owning group of /etc/sudoers back to root (equivalent to chgrp root /etc/sudoers). Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| group | root |
|---|---|
| path | /etc/sudoers |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root group on /etc/sudoers is a privilege-escalation risk. Restoring group root is non-disruptive: sudo reads the file as root and refuses to run if it is writable by non-owners anyway. Precaution: never edit /etc/sudoers directly, use visudo to avoid a syntax error that would lock everyone out of sudo; keep the mode at 0440.
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.