Writing sudoers Rules That Are Actually Least-Privilege

The phrase "just add them to the sudo group" is how most administrators grant admin access, and it is almost always too much. A sudo user who can run any command under nobody's scrutiny is a root-equivalent account, and the whole point of sudo's rule engine is that you do not have to hand that out. sudoers is a serious policy language, and this guide shows how to write entries that grant exactly the command you need, no more — the difference between an account that can restart nginx and an account that can replace the binary.

Why the sudo Group Is a Footgun

Membership in the sudo group on Debian-family systems expands to the entry %sudo ALL=(ALL:ALL) ALL — run anything, as any user, with no constraint. One compromised admin shell is a full compromise. Least privilege does not mean paranoia for its own sake; it means the record of what each operator may do is so precise that an incident is easy to scope and an offboarding is just revoking a name. When you can point to the exact command an account was allowed to run, you can also point to exactly what it did.

Structure Rule Files the Right Way

sudoers should never be one monolithic /etc/sudoers dump. The correct layout uses /etc/sudoers.d with one file per policy and the visudo -c check keeping everything valid. Named aliases — User_Alias, Cmnd_Alias, and Runas_Alias — turn a pile of cryptic lines into a directory of readable policy that anyone can follow.

# /etc/sudoers.d/services
Cmnd_Alias SERVICES = /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx
Cmnd_Alias JUMP = /usr/bin/reboot
deploy ALL = (ALL) NOPASSWD: SERVICES
deploy LOCAL = (ALL) JUMP

The rule lines mean "deploy may run the listed commands, from anywhere, as any user, without a password" for SERVICES, and the LOCAL host alias scope restricts the reboot grant to the local machine. Note the aliases name the exact binaries and exact subcommands. systemctl without a following restart argument would be far broader, so the fragment pins both the binary and the operation.

Restrict runas to Limit Privilege Escalation

The middle field of a sudoers rule — the runas list — is where most least-privilege effort belongs. Granting a user the ability to run a command as root is very different from granting it as a specific service account. If your deploy user only needs to maintain the Postgres service, run the systemctl restart as the postgres user with runas, not as root.

# /etc/sudoers.d/postgres
Cmnd_Alias PG = /usr/bin/systemctl restart postgresql, /usr/bin/systemctl status postgresql
pgadmin     ALL = (postgres) NOPASSWD: PG
pgadmin     ALL = (root) /usr/bin/systemctl restart postgresql

The second rule is written deliberately to show the alternative: allowing the same restart as root. Restricting runas to (postgres) means even if the account is abused, the most the attacker gains is the privileges of the postgres user — not root. Whenever a binary will happily run as a non-root service user, prefer that narrower runas target over root to contain lateral moves.

Use NOPASSWD Sparingly and With Reason

NOPASSWD is a convenience that trades safety for friction: it removes the one thing that can slow down an automated attacker. Use it only for so-called "safe" read-only or idempotent commands — status, reload, health checks — in dedicated aliases, and leave password prompts on anything destructive. The pattern above separates SERVICES from JUMP precisely so that a destructive restart of the whole machine still asks for a password while routine status checks do not.

sudo -l
sudo -k
sudo -v
server1$ sudo systemctl restart nginx

The -l flag lists exactly what the current user is allowed to run — the best self-audit tool sudo has. -k forces the timestamp to reset, and -v validates credentials. Any new rule can be verified with visudo -c before it is live, and testing a crafted rule on a non-production host is cheap insurance against locking out an admin.

Verify and Go Live Without Locking Out

A typo in sudoers can lock every administrator out of the box, which is why visudo is mandatory. It locks the file, applies a syntax check, and refuses to exit while the file is invalid. On a fleet, apply rules to one host, confirm sudo -l reflects them, then roll out.

sudo visudo -f /etc/sudoers.d/services
sudo visudo -c
grep -v '^#' /etc/sudoers /etc/sudoers.d/* | sort

The grep dumps every active, non-comment rule so you can review the complete effective policy in one shot. Keep the set of files under /etc/sudoers.d minimal, commit them to your configuration management, and treat any change to the sudo group as an incident-worthy event.

Takeaway

Least privilege with sudo is a matter of grammar: name the commands, narrow the runas target, and gate destructive operations behind a password. A rule you can point at is a permission you can audit, revoke, and defend. Netbay VPS plans give you full root on a fresh Ubuntu or Rocky host in minutes, which means the sudoers story is yours to write correctly from the very first admin account — netbayhosts.in.