Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate
Ensure no !authenticate directive appears in the sudoers policy, so every sudo invocation 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 lets users escalate to root without re-authenticating. If their session is left unlocked or hijacked, anyone at the keyboard, or a malicious process in that session, can run privileged commands silently. Requiring re-authentication ensures the person escalating is the legitimate, authorised user, and creates an authentication event 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 found. 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 authentication policy rather than one file.
describe command('grep -rqE \'^[^#]*!authenticate\' /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 is a policy that bypasses re-authentication and must be removed.
Inspect & investigate
sudo authentication events are logged to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL), and via journalctl -t sudo. With re-authentication enforced, each escalation produces a password-prompt/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: locate 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 | grep -rl '!authenticate' /etc/sudoers /etc/sudoers.d/ 2>/dev/null # remove the !authenticate directive from each with: visudo (or visudo -f /etc/sudoers.d/<file>) |
|---|---|
| reason | sudoers edits risk lockout, always edit via visudo |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Removing NOPASSWD/!authenticate will require a password for affected commands, which breaks unattended automation (cron jobs, CI runners, scripts) that relied on passwordless sudo. Before applying, identify those automated callers and move them to a dedicated service account with a tightly scoped, command-specific NOPASSWD rule, or to a secrets-aware runner, rather than leaving a blanket exemption for interactive users.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.2.5, 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 |
| DISA STIG | UBTU-22-432010, UBTU-24-300021 | direct | per OS STIG release | 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.