Ensure That the sudo Binary Has the Correct Permissions
Restricts permissions on the /usr/bin/sudo binary so it cannot be read or written by group/other, nor written by its owner.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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 sudo binary is setuid root: anyone who can run it gains a path to root privileges. Its permissions must stay tightly controlled (---x--x--x with the setuid bit). If sudo becomes writable by a non-root user, that user can replace or patch the binary and capture every invocation, including the credentials and commands of administrators, an instant privilege-escalation and credential-theft vector. Over-permissive read access also helps an attacker analyze the binary to craft exploits.
What Pavois checks
Pavois inspects the actual on-disk mode of /usr/bin/sudo and asserts it is not writable by owner/group/other and not readable/executable by group/other. The InSpec file resource reads the effective inode permissions resolved by the kernel, exactly what sudo runs with, rather than trusting a packaging manifest that may have been tampered with after install.
only_if { file('/usr/bin/sudo').exist? }
describe file('/usr/bin/sudo') do
it { should be_owned_by 'root' }
it { should_not be_writable.by('group') }
it { should_not be_writable.by('other') }
endHow to verify it is applied
Run stat -c '%U %G %a' /usr/bin/sudo. Expected: owner and group root with a mode such as 4111 (setuid, ---x--x--x). The binary must show no write bits for group or other and no read bit for group/other.
Inspect & investigate
Package integrity changes are visible with dpkg --verify sudo (Debian/Ubuntu) or rpm -V sudo (RHEL/Alma); a ..?...... or M flag on the binary signals a mode change. sudo usage itself is logged to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL).
Remediation
No automated remediation ships for this rule. Restore the package default manually: chown root:root /usr/bin/sudo then chmod 4111 /usr/bin/sudo (or re-install the sudo package to reset the vendor mode).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 4755 |
|---|---|
| path | /usr/bin/sudo |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A writable or world-readable sudo binary lets a local attacker hijack privilege escalation and steal admin credentials. Fixing it is low-risk: the correct mode is the vendor default. Do not strip the setuid bit (chmod 0111), sudo would no longer be able to elevate and every sudo command would fail with a permissions error. Keep mode 4111 so the setuid-root behavior is preserved.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R38 | 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.