The default sudo configuration caches successful authentication using a timestamp, allowing commands to execute without a password prompt for a limited period. This can cause security risks, such as local privilege escalation if an attacker accesses an unlocked terminal session or if a malicious script automatically escalates its own privileges within the cached timeframe.

Additionally, restricting the execution path ensures that sudo only executes verified, system-installed packages.

Here is how to configure sudo to require per-command authentication and restrict the execution path for commands.

Edit the sudoers file

Start modifying the /etc/sudoers configuration file by using the following command as root:

visudo

Editing /etc/sudoers file using visudo locks the file and checks the syntax before saving changes.

Requiring password authentication for every sudo command

Set timestamp_timeout to zero in the /etc/sudoers file to enforce per-command authentication:

Defaults timestamp_timeout=0

The benefit is that an attacker accessing an unlocked terminal after a legitimate sudo command cannot reuse that authorization. For example, if a system administrator runs sudo apt update and temporarily steps away from their desk without locking the screen, a malicious insider cannot walk up to the active terminal and type sudo cat /etc/shadow to extract password hashes, as the system will immediately demand the password again.

Additionally, it prevents both background processes and user-executed programs from exploiting a cached session to automatically escalate their privileges:

• In a legitimate but unintended context, a user might run a standard development command like npm install or make on a third-party project. If the project contains build hooks configured to modify system directories or install global binaries, an active sudo session allows the script to silently execute these elevated changes, completely bypassing the user's opportunity to review or approve the action.
• In a malicious context, a script running silently in the background could monitor for an active sudo timestamp. Once the user legitimately authenticates, the script exploits the cached token, for example, to append an attacker's SSH key to /root/.ssh/authorized_keys without generating a visible password prompt.

The tradeoff is requiring repeated password entry when running several privileged commands interactively.

Restricting the execution path

The secure_path directive replaces the user's PATH with a fixed value during a sudo execution:

Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin"

Update these directories to match your operating system and local administrative tools.

Validating the recommended configuration

If you choose to modify files in /etc/sudoers.d/ instead of using the visudo command, validate the configuration by running the following command as root to parse the sudo configuration files for syntax errors:

visudo -c

Conslusion

These sudo configurations provide explicit, deterministic control over privilege escalation. Forcing authentication for all elevated actions and locking the execution path to verified system directories eliminate the risk of cached credentials and manipulated environment variables. This ensures every command executed as root becomes an intentional, manually authorized event.