Ensure Users Re-Authenticate for Privilege Escalation - sudo
Ensure no !authenticate directive appears in the sudoers policy, so every sudo privilege escalation requires the user to re-enter their password.
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
An !authenticate (or NOPASSWD) rule allows privilege escalation without re-authentication. If a session is left unlocked or hijacked, anyone present, or a malicious process within that session, can run root commands silently. Requiring re-authentication confirms the escalating user is the legitimate, authorised one and produces an authentication record for accountability.
What Pavois checks
Pavois greps the active sudoers tree, /etc/sudoers and every file under /etc/sudoers.d/, and the rule passes only when no uncommented !authenticate is present. Because sudo merges the main file with all drop-ins, scanning the whole tree catches an exemption hidden in any drop-in, reflecting the effective policy rather than one file.
describe command('grep -rqE \'^[^#]*\bNOPASSWD\b\' /etc/sudoers /etc/sudoers.d/ 2>/dev/null && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run sudo grep -rE '^[^#]*!authenticate' /etc/sudoers /etc/sudoers.d/. The expected result is no output, any matching line bypasses re-authentication and must be removed.
Inspect & investigate
On AlmaLinux, sudo authentication events are logged to /var/log/secure and via journalctl -t sudo. With re-authentication enforced, each escalation produces an authentication record; a NOPASSWD/!authenticate rule would leave the command logged but with no authentication event.
Remediation
This rule has no automated harden plan in Pavois, so it must be fixed manually: find the offending file with the grep above, then remove or comment the !authenticate / NOPASSWD directive (edit via visudo or visudo -f /etc/sudoers.d/<file> so the change is syntax-validated before saving).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # Remove NOPASSWD so sudo always authenticates. WARNING: breaks any automation relying on passwordless # sudo (including pavois's own management user), repoint it to a key/password FIRST. grep -rl 'NOPASSWD' /etc/sudoers /etc/sudoers.d/ 2>/dev/null # then edit each with: visudo (or visudo -f /etc/sudoers.d/<file>) and delete the NOPASSWD tag |
|---|---|
| reason | dropping NOPASSWD breaks passwordless automation (incl. pavois), repoint it first |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Requiring a password for previously passwordless commands breaks unattended automation (cron jobs, CI runners, scripts) that depended on NOPASSWD sudo. Before applying, locate those automated callers and migrate them to a dedicated service account with a narrowly scoped, command-specific NOPASSWD rule, rather than leaving a blanket exemption for interactive users.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.2.4 | direct | per OS, see the benchmark table | high |
| NIST | IA-11, CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| 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.