Require Re-Authentication When Using the sudo Command
Forbid Defaults timestamp_timeout=-1 in sudoers. A value of -1 makes the sudo credential cache never expire: the user authenticates once and is never asked again for the whole life of the terminal. Removing it restores sudo's default 15-minute re-authentication window.
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
Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate.
What Pavois checks
Pavois runs grep -rqE 'timestamp_timeout[[:space:]]*=[[:space:]]*-1' /etc/sudoers /etc/sudoers.d/: a hit yields ko (fail), no hit yields ok (pass). The grep is recursive over the drop-in directory, so a -1 hidden in a file under /etc/sudoers.d/ is caught, exactly where sudo would read it. The control rejects only the -1 sentinel: the built-in default and any explicit non-negative timeout both pass. Evidence is typed persistent-config because sudo has no queryable daemon: the policy is parsed at each invocation.
describe command('grep -rqE \'timestamp_timeout[[:space:]]*=[[:space:]]*-1\' /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 'timestamp_timeout' /etc/sudoers /etc/sudoers.d/: no line may set the value to -1 (no output at all is a pass). Then test the behaviour:
sudo -k # drop the cached credential
sudo -v # must prompt for the password
sudo -v # no prompt: the cache is warm
After the timeout elapses, sudo -v must prompt again. If it never does, a -1 is still in effect somewhere.
Inspect & investigate
sudo writes its authentication events to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL), reachable with journalctl -t sudo. A failed prompt shows as:
sudo: pam_unix(sudo:auth): authentication failure; logname=alice uid=1000 euid=0 tty=/dev/pts/0 ruser=alice rhost= user=alice
Beware of the blind spot this rule closes: reusing the cached credential produces no log entry at all. The cache is a timestamp file under /run/sudo/ts/<user>, and with timestamp_timeout=-1 an attacker's commands would show up as ordinary COMMAND= lines with no authentication event ever preceding them. If sudo-custom-logfile is applied, the same command lines are also written to /var/log/sudo.log.
Remediation
The Pavois plan is deliberately manual (resource: manual, reason: sudoers edits risk lockout, always edit via visudo). It reports the offending files with grep -rl 'timestamp_timeout[[:space:]]*=[[:space:]]*-1' /etc/sudoers /etc/sudoers.d/; you then remove the timestamp_timeout=-1 line from each one with visudo (visudo for the main file, visudo -f /etc/sudoers.d/<file> for a drop-in). Sudo falls back to its 15-minute default as soon as the line is gone. No automated write, no service to reload.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | grep -rl 'timestamp_timeout[[:space:]]*=[[:space:]]*-1' /etc/sudoers /etc/sudoers.d/ 2>/dev/null # remove the 'timestamp_timeout=-1' line from each with visudo (default is 15min re-auth) |
|---|---|
| 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
With timestamp_timeout=-1, one password entry covers the entire session: anyone who takes over an open terminal, an unlocked workstation or a hijacked SSH session runs root commands without ever meeting a prompt, and the re-authentication requirement (NIST IA-11) is defeated in practice. Applying the fix simply restores the prompts; the operational cost is more password entries for admins running long batches, which sudo -v (refresh) or a sensible positive timeout handles, never -1. The real risk is the edit itself: a syntax error in sudoers locks everyone out of root. Always use visudo, which refuses to save an invalid file, and keep a second root session open until you have confirmed sudo -v still works.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.2.6 | direct | per OS, see the benchmark table | high |
| NIST | IA-11 | 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.