Skip to content
stellvia.dev

Users and sudo

After obtaining a shell, check the executing user and groups before searching for vulnerabilities. This page covers UIDs, supplementary groups, users who can log in, and interpreting sudo -l. For allowed commands, continue with Programs Allowed Through sudo.

Commands to check

Section titled “Commands to check”

Additional check examples:

Terminal window
id
whoami
groups
getent passwd
getent group
umask
sudo -l
  • Purpose: Identify the current UID/GID, supplementary groups, users who can log in, and boundaries sudo can cross.
  • Prerequisites: An interactive shell. sudo -l may request a password.
  • What to inspect: uid=, gid=, groups=, login shells such as /bin/bash, NOPASSWD, SETENV, wildcards, argument restrictions, and deny rules.
  • Expected output: (root) NOPASSWD: /usr/bin/python3 /path/script.py, Sorry, user ... may not run sudo, or Command 'sudo' not found.
  • Interpretation: If sudo is unavailable, investigate localhost services, systemd, writable paths, and credentials. If it is available, trace what the allowed command reads as root.
  • If a check fails: Distinguish absence of sudo, lack of a TTY, password prompts, exact sudoers matching, and restrictions on extra arguments.
  • Alternative commands: cat /etc/passwd, find /etc/sudoers.d -maxdepth 1 -type f -readable -print, doas -C /etc/doas.conf.
  • State change: id and getent are read-only. sudo -l may appear in authentication logs. Do not repeatedly enter an incorrect password.

Reading the output

Section titled “Reading the output”
  • uid=1000(user) is the real UID. If euid=0(root) appears after running a SUID binary, the effective UID is root.
  • Supplementary groups affect access to writable directories and sockets.
  • A * in sudo -l does not necessarily permit arbitrary arguments. Read the full path, arguments, deny rules, and environment resets.
  • A shell in /etc/passwd is not enough. Check service users’ home directories and groups too.
  • Record Web or printing service accounts separately from users with login shells.
  • The UID in /proc/net/tcp is the effective UID at socket creation. Identify the listener process with ss -p or /proc/<PID>/fd before checking its executing user.
  • If sudo is denied, stop trying variants of the allowed command. The next candidate is a privileged localhost service.

General principle: UID/GID directly affect file permissions, socket access, process visibility, and SUID behavior.

Exact matching, denied subcommands, and files read by allowed sudo commands are covered under Programs Allowed Through sudo.