Enforce Usage of pam_wheel with Group Parameter for su Authentication
Enables pam_wheel.so use_uid in /etc/pam.d/su so only members of a trusted admin group (e.g. wheel/sudo) may use su to become another user, typically root.
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
su lets a user switch to another identity, usually root, given the target password. Without pam_wheel, any local user who learns or brute-forces the root password gains a root shell. Restricting su to a defined administrative group with pam_wheel.so use_uid adds a membership gate on top of the password, enforcing least privilege and ensuring privilege escalation is limited to an auditable, intentional set of accounts.
What Pavois checks
Pavois greps the active PAM service file /etc/pam.d/su for an uncommented pam_wheel.so ... use_uid line. This is the file PAM actually loads when su runs, so reading it reflects the policy in force; use_uid is required so the check is based on the real UID of the caller, not an assumed identity.
describe command('grep -qrE \'^[^#]*pam_wheel.so.*use_uid\' /etc/pam.d/su 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run grep -E '^[^#]*pam_wheel.so.*use_uid' /etc/pam.d/su. The expected output is an active line such as auth required pam_wheel.so use_uid. Test by attempting su - as a user not in the admin group, it should be denied.
Inspect & investigate
su attempts and PAM decisions are logged in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL), and via journalctl. A denied attempt appears as pam_wheel(su:auth): ... not in the trusted group.
Remediation
No automated harden plan is defined, so this must be applied manually: in /etc/pam.d/su uncomment or add auth required pam_wheel.so use_uid (optionally group=wheel/group=sudo), and make sure your administrators are members of that group. Changes take effect immediately for new su invocations.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | sed -ri 's/^#\s*(auth\s+required\s+pam_wheel\.so.*use_uid)/\1/' /etc/pam.d/su; grep -qE '^[^#]*pam_wheel\.so.*use_uid' /etc/pam.d/su || echo 'auth required pam_wheel.so use_uid' >> /etc/pam.d/su |
|---|---|
| name | pam-wheel-su |
| not_if | grep -qE '^[^#]*pam_wheel\.so.*use_uid' /etc/pam.d/su |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If you enable pam_wheel before adding your admin accounts to the trusted group, those users lose the ability to su to root, which can hamper recovery on systems without working sudo. Before applying, populate the group (usermod -aG wheel <admin> or sudo on Debian/Ubuntu), keep an existing root or sudo session open, and verify a member can still su - before relying on it.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 5.2.7 | 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.