sudo

sudo (“superuser do”) is the standard Unix mechanism for letting an unprivileged user run commands as another user — most commonly root — subject to policy defined in /etc/sudoers. Where su requires the target user’s password, sudo requires the caller’s password (or none, for NOPASSWD entries), and it logs every invocation, which makes it both an administrative control and a rich audit trail.

sudoedit is the file-editing sibling: instead of handing the user a root shell on an editor, sudo copies the target file to a temporary location, runs the user’s editor as the unprivileged user, and copies the result back as root. This closes the classic sudo vim /etc/shadow → :!sh shell-escape path — though see vim-shell-escape for why editor escapes still matter when admins grant sudo vim directly.

/etc/sudoers and visudo

Policy lives in /etc/sudoers (plus drop-ins under /etc/sudoers.d/). The file is edited only via visudo, which syntax-checks before saving — a malformed sudoers can lock every user out of privilege. A minimal entry:

alice ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

Fields are: user, host, (run-as user), optional NOPASSWD:, and the permitted command(s). Wildcards and command groups (Cmnd_Alias) make it easy to over-grant — /usr/bin/* with a single GTFOBins-listed binary in it is a root shell.

Enumeration: sudo -l

The single most useful privilege-escalation reconnaissance command on a Linux host:

sudo -l

reports the current user’s permitted commands, run-as specs, and — critically — any preserved environment variables (env_keep entries such as LD_PRELOAD / LD_LIBRARY_PATH). Full workflow and caveats (logging, the “user may not run sudo” case) are in sudo-nopasswd-recon.

Environment: env_keep and the LD_PRELOAD path

By default sudo resets the environment (env_reset). Any env_keep += "LD_PRELOAD LD_LIBRARY_PATH" line in sudoers passes those variables straight through to the root-spawned process, handing the caller a code-injection primitive — the ld-preload-trick. Auditing sudoers for these lines is a standard hardening step.

GTFOBins relevance

Any binary reachable through a sudo rule should be looked up in GTFOBins under the sudo category. Many everyday tools — tar, find, awk, less, vim, nmap, scp — have documented shell, file-read, or file-write primitives when run with elevated privilege. See awk-shell-escape, vim-shell-escape, tar for worked examples.

Related

• sudo-nopasswd-recon — the sudo -l enumeration playbook
• ld-preload-trick — env_keep → root code injection
• gtfobins — per-binary abuse catalog
• unix-permissions — the privilege model sudo sits on top of
• polkit-privilege-escalation — the other Linux privilege-boundary abuse
• cat — a frequently-seen sudo -l entry that grants root file read
• debian-dpkg-file-lookup — dpkg-query -l is the parallel “what’s installed” recon step

Sources

• sudo(8) — execute a command as another user
• sudoers(5) — default sudo security policy plugin
• Sudo — Official Documentation
• GTFOBins