Whoever has sudo effectively has root. During a security review, “who can become root on this host?” is one of the first questions to answer, and the answer is rarely in one place.

Membership of the sudo group is only part of it. Rules in /etc/sudoers and /etc/sudoers.d/ can grant access to individual users, to other groups, or to a single command that is as good as a root shell.

Check Sudo Groups

Start with the groups that grant sudo by default. It’s sudo on Debian and Ubuntu, wheel on RHEL and Fedora, and admin on older Ubuntu releases:

getent group sudo wheel admin

Anyone listed after the last colon is a member. getent also works when users come from LDAP or SSSD, which grep /etc/group would miss.

Read the Sudoers Rules

Now read the rules themselves, with comments and blank lines removed:

sudo grep -rEv '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

-r walks the sudoers.d directory, and grep prefixes each line with its file name, so you can see which drop-in granted what. Lines starting with % are groups, anything else is a user.

Group membership is only half the answer.

A user can have no sudo group at all and still run commands as root through a line in sudoers.d. Check both.

List Effective Privileges per User

To see what one account can do after groups and rules are combined:

sudo -l -U username

To sweep every account on the host and print only those with sudo rights:

getent passwd | cut -d: -f1 | while read -r u; do
  sudo -l -U "$u" 2>/dev/null | grep -q 'is not allowed' || echo "$u"
done

Service accounts with a NOPASSWD rule show up here too, even though they never appear in a group.

What to Flag

  • NOPASSWD: root without re-authenticating. Acceptable for a narrow automation task, a finding for a human admin account.
  • ALL=(ALL) ALL for a broad group: every member is a full administrator.
  • Wildcards in allowed commands: /usr/bin/systemctl * nginx lets the user pass options you didn’t intend.
  • Shell-escape binaries: vim, less, find, tar, git and many others can spawn a root shell. GTFOBins lists which.

To see whether the access is actually used, check the log:

sudo journalctl _COMM=sudo --since "30 days ago"

On systems without journald, look in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL).

Remove Access Safely

Edit sudoers only with visudo, which validates syntax before saving. A broken sudoers file can lock everyone out of root:

sudo visudo -f /etc/sudoers.d/deploy
sudo gpasswd -d username sudo

Prefer a drop-in per purpose over editing /etc/sudoers directly, and grant exact commands rather than ALL.

Inventory the groups, read the rules, check effective privileges, then flag what’s broader than the job needs. Next in this Linux audit series: SUID/SGID binaries, which hand out elevated privileges without sudo, and the world-writable files that privileged processes may trust.