L7. Sudo Configuration and Least Privilege

What sudo Does

sudo stands for "superuser do." It allows a permitted user to execute a command as root (or another user) without logging in as root directly. This is the foundation of the principle of least privilege on Linux: users operate with normal permissions and elevate only when necessary, only for the specific command they need.

When you run a command with sudo:

1. The system checks if your user is authorized in /etc/sudoers
2. It prompts for your password (not root's password)
3. If authenticated and authorized, the command runs with elevated privileges
4. The command, the user, the timestamp, and the result are logged

# Run a single command as root
sudo systemctl restart nginx
# Open an interactive root shell (use sparingly)
sudo -i
# Run a command as a different user
sudo -u www-data whoami
# Check what sudo commands you are allowed to run
sudo -l

The sudo -l command is valuable both for administrators auditing access and for penetration testers enumerating what a compromised account can do.

The /etc/sudoers File

All sudo authorization rules live in /etc/sudoers. This file controls who can use sudo, what commands they can run, and under what conditions.

Never Edit Directly

Always use visudo to edit the sudoers file:

sudo visudo

visudo opens the file in a text editor and validates the syntax before saving. A syntax error in /etc/sudoers can lock every user out of sudo, potentially requiring you to boot into recovery mode to fix it. Editing the file directly with nano or vi offers no such protection.

sudoers Syntax

The basic format is:

user  host=(run_as_user)  commands

Examples:

# Allow idan to run ALL commands as root on ALL hosts
idan    ALL=(ALL)    ALL
# Allow the "security-team" group to run ALL commands
%security-team    ALL=(ALL)    ALL
# Allow analyst to restart nginx and view logs only
analyst    ALL=(root)    /usr/bin/systemctl restart nginx, /usr/bin/journalctl

The % prefix indicates a group. ALL is a wildcard that matches any host, user, or command.

Drop-in Configuration Files

Modern distributions support a directory-based approach that is cleaner than editing the main sudoers file:

# Create a file in /etc/sudoers.d/ for specific roles
sudo visudo -f /etc/sudoers.d/security-team

Contents:

%security-team    ALL=(root)    /usr/bin/nmap, /usr/bin/tcpdump, /usr/bin/ss

This approach keeps configurations modular and makes it easy to audit who has what access. Each file in /etc/sudoers.d/ is included automatically.

Granting Specific Command Access

The principle of least privilege says: give each user only the permissions they need to do their job. With sudo, this means specifying exact commands rather than granting blanket ALL access.

Good: Specific Commands

# The backup operator can only run backup-related commands
backup-operator    ALL=(root)    /usr/bin/rsync, /usr/bin/tar, /usr/bin/mount

Bad: Overly Broad Access

# Giving ALL access to non-admin users defeats the purpose of sudo
intern    ALL=(ALL)    ALL

Dangerous: Unrestricted Editors or Shells

# NEVER do this: editors and shells allow escaping to a root shell
analyst    ALL=(root)    /usr/bin/vi
analyst    ALL=(root)    /bin/bash

Granting sudo access to a text editor like vi is equivalent to granting full root access. Users can escape from the editor to a shell running as root (:!bash in vi). The same applies to less, man, awk, find (with -exec), and many other commands. Be aware of GTFOBins (https://gtfobins.github.io) which catalogs commands that can be exploited for privilege escalation.

NOPASSWD: The Convenience vs. Security Trade-Off

The NOPASSWD directive allows running sudo commands without entering a password:

# Run systemctl without a password prompt
deploy-bot    ALL=(root)    NOPASSWD: /usr/bin/systemctl restart myapp

When NOPASSWD Is Acceptable

• Service accounts used by automation (CI/CD pipelines, configuration management tools) that have no human at the keyboard to type a password
• Extremely limited, specific commands for monitored service accounts

When NOPASSWD Is Dangerous

# NEVER do this: any command as root without authentication
developer    ALL=(ALL)    NOPASSWD: ALL

If this user's account is compromised (stolen SSH key, session hijack, credential reuse), the attacker immediately has passwordless root access to the entire system.

Sudo Logging: The Accountability Layer

Every sudo invocation is logged. This is one of the primary reasons to use sudo instead of direct root login.

Where Sudo Logs Are Stored

# Ubuntu/Debian
cat /var/log/auth.log | grep sudo
# RHEL/CentOS
cat /var/log/secure | grep sudo

What Gets Logged

Each log entry includes:

• The user who ran sudo
• The command that was executed
• The timestamp
• Whether the attempt was successful or denied
• The terminal (TTY) where the command was run

Example log entries:

Jun 20 14:32:01 server sudo: idan : TTY=pts/0 ; PWD=/home/idan ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
Jun 20 14:35:22 server sudo: intern : command not allowed ; TTY=pts/1 ; PWD=/home/intern ; USER=root ; COMMAND=/usr/sbin/useradd hacker

The second entry shows a denied attempt: the user "intern" tried to run useradd but was not authorized. This kind of entry is valuable for detecting insider threats or compromised accounts probing for access.

Enhanced Logging with sudo I/O Logging

For high-security environments, sudo can log the entire input and output of commands:

# In /etc/sudoers:
Defaults    log_input, log_output
Defaults    iolog_dir=/var/log/sudo-io

This creates a full session transcript, which is invaluable for forensic investigations but generates significant storage overhead.

Sudo Timeout and Session Configuration

# In /etc/sudoers:
# Require password every time (no caching)
Defaults    timestamp_timeout=0
# Cache credentials for 5 minutes (default is usually 5 or 15)
Defaults    timestamp_timeout=5
# Require password for specific users even if others have a timeout
Defaults:analyst    timestamp_timeout=0

A timeout of 0 means every sudo command requires a password. This is more secure but less convenient. Choose the timeout based on your environment's threat model.

Auditing sudo Configuration

Regular audits of sudo access should be part of your security baseline:

# View the full effective sudoers configuration
sudo cat /etc/sudoers
sudo ls -la /etc/sudoers.d/
# Check what specific users can do
sudo -l -U analyst
sudo -l -U deploy-bot
# Search for NOPASSWD entries
sudo grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/
# Search for ALL access (overly broad)
sudo grep -r "(ALL)" /etc/sudoers /etc/sudoers.d/ | grep -v "^#"

Flag any user with NOPASSWD: ALL or with sudo access to editors, shells, or interpreters. These are the highest-risk configurations.