blog.6admin.io
guest@6admin.io:~$
devops, linux, security

Root or not root

The question: who gets to be root on a shared server? The answer is not technical, it is political. But the technical tools exist and they are not equal.

su

su asks for the root password. Whoever knows it becomes root. Period. All admins share the same password and when someone leaves the team, it needs changing (and redistributing). The history of what was done as root is limited to last and the memory of whoever was there.

sudo

sudo asks for the USER’s password (not root’s) and executes the command specified in /etc/sudoers. The advantage: every root action goes through the sudo log (/var/log/auth.log), each user keeps their own password and the sudoers file controls WHO can do WHAT.

# /etc/sudoers
%admin ALL=(ALL) ALL           # the admin group can do everything
user1 ALL=(root) /etc/init.d/apache2 restart   # user1 can restart Apache
user2 ALL=(root) NOPASSWD: /usr/bin/apt-get    # user2 can apt-get without password

The NOPASSWD line is the kind of thing that saves time and loses security at the same time: if user2’s account is compromised, the attacker has apt-get as root, which means installing arbitrary packages, which means full root. NOPASSWD has a cost and it must be known.

The sudoers file

The file is modified with visudo, never with vim direct (visudo checks syntax before saving, a broken sudoers = no sudo at all). The syntax:

who       where=(as whom)     what
user      ALL=(root)          /usr/bin/passwd
%group    ALL=(ALL)           ALL

What I do

On my servers, PermitRootLogin no in sshd_config, root is never directly SSH-accessible. Admins go through their account and sudo su - (or sudo -i). The sudoers limits commands to necessary operations and sudo logs track what was done, by whom, when.

The sudo su - command gives a full root shell, which bypasses sudoers granularity. But it is logged (the entry into the root shell is traced) and after that it is the admin’s responsibility. The sudoers limits entry, not behavior once inside.

[edit: 2026] The sudo model described in this article has been demolished since. Not by a bug, by an awareness: GTFOBins (gtfobins.github.io ) catalogued that almost ANY binary present on a Linux system can be used to escalate to a root shell when launched via sudo.

The NOPASSWD I recommended in this article:

user2 ALL=(root) NOPASSWD: /usr/bin/apt-get

is not a limitation, it is a full root grant in disguise. apt-get executes pre/post hooks as root. A custom package, a malicious config file and user2 has root without touching su. The same reasoning applies to:

sudo vim file       → :!/bin/sh        → root shell
sudo find . -exec /bin/sh \;           → root shell
sudo less file      → !/bin/sh         → root shell
sudo awk 'BEGIN{system("/bin/sh")}'    → root shell
sudo python -c 'import os;os.system("/bin/sh")'  → root shell
sudo nmap --interactive                → !sh → root shell
sudo systemctl edit service            → edit a unit file = root

The list is encyclopedic. GTFOBins documents every binary, every escape, every one-liner. The conclusion is brutal: sudoers granularity is theater as long as the allowed binaries are on the GTFOBins list. A sudo /usr/bin/passwd user may look safe: passwd calls root helpers and some of them can be exploited.

Modern countermeasures:

  • sudoedit instead of sudo <editor>: sudoedit copies the file, runs the editor unprivileged, copies back. The editor does not run as root, so no shell escape;
  • The NOEXEC tag: user2 ALL=(root) NOEXEC: /usr/bin/command prevents the binary from fork/execing a subprocess (but there are workarounds);
  • Wrapper scripts that do exactly the needed action, instead of granting access to the generic tool;
  • sudo -l as audit: every user can list what they can do as root. The output is the attack surface and it should be compared against the GTFOBins list;
  • CVE-2021-3156 (Baron Samedit): a heap overflow in sudo’s argument parsing, exploitable by any local user, without needing to be in the sudoers, affecting versions 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1 (check against your sudo --version). CVE-2019-14287: sudo -u#-1 bypasses the user check. sudo itself is an attack surface, not just what it allows you to do.

The 2026 moral: sudoers limits what sudoers can limit. GTFOBins proved that what sudoers can limit is almost nothing, as long as the user has access to an interpreter. The real security is not in the sudoers file, it is in isolation (containers without sudo, chroot, namespaces) and in privilege separation by process.