Root vs sudo — the production privilege model · Linux

sudo is the canonical privilege-escalation tool on modern Linux. Every production host ships with it; every policy document references it; every compliance audit checks it. Understanding sudo is not optional.

The historical alternative to sudo was su - (or just logging in as root directly). Both produce the same outcome: a session with UID 0. Both have the same problem: the audit trail is what the root user decides to write down.

sudo’s discipline is different:

Concern	`su -`	`sudo`
Per-command audit	The `su` invocation is logged; the resulting commands are not.	Every command is logged with timestamp, user, TTY, and command.
Per-user access	“Members of `wheel` get root”	Each user gets a specific list of allowed commands.
Password exposure	Root password is shared with everyone in `wheel`.	Each user authenticates with their own password; the root password is not shared.
Time-limited escalation	Permanent session.	By default, escalation lasts 5 minutes (configurable); re-authentication required after.
Per-host granularity	Global.	Each host’s /etc/sudoers is independent.

Read-only / Safesudo -l— sudo -l lists what the current user is allowed to run. (ALL) ALL means 'as any user, run any command' — the most permissive policy. Production should be tighter.

$ sudo -l

Matching Defaults entries for alice on host01:
env_reset, mail_badpass, secure_path=/usr/local/sbin\\:/usr/local/bin\\:/usr/sbin\\:/usr/bin\\:/sbin\\:/bin, use_pty

User alice may run the following commands on host01:
(ALL) ALL

Illustrative output

The sudo authentication flow

How sudo authenticates

When you invoke sudo command, the following happens:

sudo reads /etc/sudoers (and files in /etc/sudoers.d/) to determine whether your user is allowed to run the command.
If yes, sudo asks for your password (unless NOPASSWD applies). Authentication is via PAM, so /etc/pam.d/sudo governs the policy.
After authentication, sudo records the event to syslog and forks the command with the target user’s privileges.
A timestamp file (/var/db/sudo or /var/run/sudo) remembers the authentication for timestamp_timeout minutes (default 5).
If sudo is invoked again within the timeout, no re-authentication is required. After the timeout, the next invocation prompts again.

The timestamp file means an unattended terminal leaves an authentication window. Production hosts should set timestamp_timeout=0 for unattended workstations and rely on short timeouts (5-15 minutes) for servers.

Common sudo invocations

Configuration changecommon sudo invocations— sudo COMMAND runs the command as root. sudo -u USER runs as a different user. sudo -i starts an interactive root shell (avoid in production). The whoami after sudo -u www-data returns the user the shell is now running as.

$ sudo systemctl status ssh; sudo -u www-data whoami; sudo -i

● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since ...
www-data
root

Illustrative output

Audit trail

Read-only / Safesudo audit— journalctl _COMM=sudo shows every sudo invocation: timestamp, user, TTY, working directory, target user, and command. This is the production audit trail — set up a log forwarder to ship these to your SIEM.

$ journalctl _COMM=sudo -n 20 --no-pager

Aug  9 12:00:01 host sudo[12345]:  alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/systemctl status ssh
Aug  9 12:00:42 host sudo[12346]:  alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/systemctl restart ssh

Illustrative output

NOPASSWD and its risks

NOPASSWD removes the password prompt. Used carelessly, it turns sudo into the very thing it was designed to replace: a permanent elevation.

Configuration changeNOPASSWD— sudo -n means 'non-interactive mode' — fail rather than prompt. If your sudoers entry has NOPASSWD, this works without re-authentication. Useful for service accounts that need root; dangerous for human users because an unattended terminal inherits the elevation.

$ sudo -n systemctl status ssh

Active: active (running)

Illustrative output

ALL=(ALL) NOPASSWD: ALL is the worst possible sudoers entry

Some legacy defaults grant every member of sudo or wheel the ability to run anything without a password. An unattended terminal inherits the elevation; a stolen SSH session becomes a permanent root shell; a single phishing-resistant credential becomes a password-less root pivot. Audit your sudoers: grep -r NOPASSWD /etc/sudoers* should return nothing for human users.

For service accounts that need root, use a tightly-scoped rule:

myapp ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp.service

The NOPASSWD is restricted to one command, which is exactly what the service needs.

Production discipline

Practice	Why
Disable direct root login (`PermitRootLogin no` in sshd_config, `passwd -l root`)	Forces every privileged action through sudo, which is auditable.
Disable `su` (remove the `su` PAM group, or remove `wheel` membership)	Forces every privileged action through sudo, not the unaudited `su` flow.
Use `/etc/sudoers.d/<service>` drop-in files	Keeps each service’s policy in its own file, easy to audit and version-control.
Always run `visudo` to edit sudoers	Locks the file during edit and validates syntax. A broken sudoers file can lock all admins out of root.
Forward the journal to your SIEM	The audit trail is the only post-incident record of what privileged actions occurred.
Set `timestamp_timeout` to a short value (5-15 minutes)	Limits the window of unattended-terminal abuse.

Why direct root login is forbidden

The sudo authentication flow

Common sudo invocations

Audit trail

NOPASSWD and its risks

Production discipline

Knowledge check