sudo, su, Privilege Boundaries, and Least Privilege

1. Privilege boundaries are policy boundaries

Linux uses separate identities so ordinary work does not automatically have unrestricted authority. The root account has UID 0 and bypasses many discretionary checks, so moving into root context is not merely a convenience—it crosses a high-impact security boundary. A mature workflow elevates only for the operation that requires it, records who requested the action, and returns immediately to an unprivileged context.

flowchart TD
  U["Unprivileged user"] --> R["sudo request"]
  R --> A["Authenticate according to policy"]
  A --> P["Evaluate sudoers rules"]
  P -->|deny| D["Reject and log"]
  P -->|allow| E["Build controlled environment"]
  E --> T["Execute as target user"]
  T --> L["Record result and return"]

2. sudo and su solve different problems

su changes user context; it does not inherently provide fine-grained command policy or per-command attribution. sudo evaluates configured authorization and can log the invoking user. Neither tool makes an unsafe command safe.

# Inspect the current identity and available sudo policy
id
sudo --list

# Show a command that needs no root privilege
systemctl --user status 2>/dev/null || true

# Run one read-only command as root, if policy permits
sudo id

# Run a read-only identity check as another account
# Replace daemon only if it exists locally.
getent passwd daemon >/dev/null && sudo -u daemon id

3. Read sudoers as an authorization language

A sudoers specification identifies who may run what, on which hosts, as which target users and groups, with which tags. The apparent simplicity of a line can hide broad authority. A permitted editor, pager, interpreter, package manager, archive tool, or command with a shell escape may provide an indirect root shell.

Use visudo because it locks and validates the policy. Put local rules in a clearly named file under /etc/sudoers.d, make it root-owned and mode 0440, and validate the complete configuration before ending the current administrative session.

# Conceptual form only
who  where = (run-as-user:run-as-group) tags: command

# Example of a narrow command rule
%da-operators ALL=(root) /usr/local/sbin/da-host-summary

4. Design least-privilege elevation

Avoid casual NOPASSWD use. It may be appropriate for tightly constrained automation, but it removes an interactive authentication checkpoint and increases the impact of a compromised account or unattended session.

5. Hands-on lab: delegate one read-only operation

Run this only on a disposable lab VM. The lab creates a group, installs a root-owned helper that accepts no arguments, delegates exactly that helper, validates the rule, and then removes the configuration.

lab_group=da-operators
helper=/usr/local/sbin/da-host-summary
rule=/etc/sudoers.d/da-host-summary

# Create the delegation group and add the current user.
# A new login session is normally needed for membership to take effect.
sudo groupadd --force "$lab_group"
sudo usermod --append --groups "$lab_group" "$USER"

# Install a root-owned helper. It refuses all arguments.
tmp=$(mktemp)
cat > "$tmp" <<'SCRIPT'
#!/usr/bin/env bash
set -euo pipefail
if (($# != 0)); then
  printf 'This command accepts no arguments.\n' >&2
  exit 64
fi
printf 'host=%s\n' "$(hostname)"
printf 'kernel=%s\n' "$(uname -r)"
printf 'uptime_seconds='
cut -d. -f1 /proc/uptime
SCRIPT
sudo install -o root -g root -m 0755 "$tmp" "$helper"
rm -f "$tmp"

# Create and validate the sudoers fragment.
printf '%%%s ALL=(root) %s\n' "$lab_group" "$helper" | sudo tee "$rule" >/dev/null
sudo chmod 0440 "$rule"
sudo visudo -cf "$rule"
sudo visudo -c

# Start a new login before this test if the group was newly added.
sudo --list
sudo "$helper"

# Negative test: arguments must be rejected by the helper.
if sudo "$helper" unexpected; then
  printf 'Negative test unexpectedly succeeded.\n' >&2
  exit 1
fi

# Cleanup after testing.
sudo rm -f "$rule" "$helper"
sudo gpasswd --delete "$USER" "$lab_group" 2>/dev/null || true
sudo groupdel "$lab_group" 2>/dev/null || true
sudo visudo -c

6. Privilege-delegation hazards

7. Knowledge check

8. Summary

Privilege elevation is an authorization workflow, not a shortcut. Prefer one command over a root shell, a dedicated target identity over UID 0, a protected purpose-built helper over generic powerful tools, and validated, logged policy over informal administrative groups. The goal is the smallest auditable authority that completes the task.

9. Further reading

• sudo(8), sudoers(5), visudo(8), and sudo.conf(5).
• su(1) and your distribution's PAM configuration.
• Sudo project's security guidance on command matching, wildcards, environment, and logging.
• Organizational privileged-access management and break-glass procedures.