Sudo's credential cache needs session-aware timestamp records

Sudo does not prompt for a password on every command. It keeps a timestamp record so that a user who has recently authenticated can run another permitted command for a short period. The record's scope is controlled by timestamp_type, and that choice affects whether a password entered in one session can authorize a different session.

What the timestamp record contains

The sudoers manual describes a per-user timestamp record containing the user ID, terminal session ID, the start time of the session leader or parent process, and a timestamp. The default behavior uses a separate record for each terminal, so two login sessions normally authenticate separately.

With timestamp_type=global, sudo uses one record for the user. With tty, it includes the terminal device number and allows per-terminal granularity, although a record can outlive the terminal in some cases. With ppid, the parent process identity is the relevant context rather than a terminal that may not exist.

The default is not a perfect session boundary. On systems where a process start time is available, sudo records the start time of the session leader. That prevents many cases in which a new login reuses an old record. The manual also notes that a graphical environment may allow an unprivileged user to change the system clock, which is why sudo uses a monotonic clock where available.

Where shared timestamps become a risk

timestamp_type=global is attractive in support environments because one successful authentication can serve several administrative terminals. It also makes the cache less sensitive to the exact login context. On a multiuser workstation, a terminal multiplexer, or a long-lived remote session, that convenience can widen the window in which a forgotten session authorizes another command.

The risk is not that sudo has become unauthenticated. The user still needs an allowed command and, after the timestamp expires, a password. The issue is the assumptions in the authorization narrative: an operator may believe that a password prompt belongs to a particular session when the policy actually treats all sessions as one principal.

The record directory and ownership matter too. A cache file that can be replaced or misread may create availability or audit problems. The time stamp directory should have a narrow ownership and mode appropriate to the sudo implementation, and stale records should be removed deliberately rather than left to accumulate across image builds.

Choose the policy from the access model

For ordinary SSH administration, keep a session-scoped setting unless a documented workflow requires otherwise. A policy like this makes the boundary explicit:

Defaults timestamp_type=tty
Defaults timestamp_timeout=5

Use ppid where terminal identity is unreliable but parent-process identity remains meaningful. Do not switch to global merely to reduce prompts in a shared service account. If a service needs noninteractive privilege, use a dedicated service account, a constrained command rule, or an approved automation credential instead of extending an interactive cache.

Test the behavior from two separate login sessions. Authenticate once, run a permitted command without a password, then try the same command from the second session and verify that a password is required. Open a third session after logging out and confirm that the session start time does not permit reuse. Run sudo -k in a test session and verify that the record is invalidated.

Audit the exception instead of hiding it

Record which systems use a nondefault timestamp type and why. Review sudoers changes through the same controlled path as other privilege policy. Log successful and denied commands, retain the relevant account and session identifiers, and make sure support staff know how to revoke an interactive cache when a laptop is lost or a remote session is handed over.

The timestamp cache is useful because it reduces repeated prompts without turning every command into a password ceremony. Its security value depends on matching the cache scope to the way people actually obtain and share sessions. Session-aware records are a small control with a direct effect on who can act without another authentication event.

References

• Linux man-pages, sudoers(5)
• Linux man-pages, sudoers_timestamp(5)
• Sudo project, sudo(8)