🛂 Managing sudo and Linux Permissions Without Footguns

Permissions are where good intentions go to die. Someone needs to restart one service, so they get full sudo, and now your least-privilege model is a single line that reads deploy ALL=(ALL) NOPASSWD: ALL. Multiply that by a team and a few years, and your sudoers file is an audit nightmare.

After 25 years of cleaning these up, here’s how I think about Linux permissions and sudo, and where AI helps audit without handing you a config that breaks root.

Read permissions the way the kernel does

ls -l output is three triplets — owner, group, other — plus special bits:

-rwxr-x---  1 deploy webteam  4096 Jun 11 10:00 deploy.sh

• owner (deploy): rwx
• group (webteam): r-x
• other: ---

Numeric mode 750 = rwx r-x ---. The mental shortcut: read=4, write=2, execute=1, add them per triplet. 750 means owner full, group read+execute, others nothing.

The kernel checks owner first, then group, then other — and stops at the first match. If you’re the owner and owner has no write bit, you can’t write even if the group can. People forget this and grant group write expecting it to help the owner. It doesn’t.

The special bits that bite

Three bits cause most “why can’t I” tickets:

• setuid (u+s, e.g. 4755) — runs as the file’s owner. sudo and passwd use this. A setuid-root binary is a privilege escalation risk; audit them.
• setgid (g+s, e.g. 2755) — on a directory, new files inherit the directory’s group. Great for shared team folders.
• sticky bit (+t, e.g. 1777) — on a directory, only the file’s owner can delete it. That’s why anyone can write to /tmp but can’t delete others’ files.

Find all setuid binaries to audit:

sudo find / -perm -4000 -type f 2>/dev/null

Paste that list to AI: “Which of these setuid-root binaries are unusual or risky on a standard Ubuntu server?” It’s a fast way to spot a planted backdoor or an over-privileged custom tool.

Grant sudo the right way: least privilege

The whole point of sudo is scoped privilege. Don’t hand out ALL. Grant exactly the commands needed, in a drop-in file under /etc/sudoers.d/:

# /etc/sudoers.d/deploy
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp, /bin/systemctl status myapp

Now deploy can restart one service and nothing else. Use a group so you manage people, not lines:

%webops ALL=(ALL) /usr/bin/systemctl, /usr/bin/journalctl

NEVER edit sudoers without visudo

This is the rule that prevents the worst outcome. A syntax error in sudoers can lock everyone out of root. visudo syntax-checks before saving:

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

If you ignore one thing in this article, make it this: visudo, never a plain editor. And keep a root shell open in another terminal while you do it, the same safety-session habit I use for SSH changes.

Watch the wildcard trap

This line looks safe and is a full root escalation:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart *

The * lets deploy run systemctl restart anything — including units they shouldn’t touch, and with some commands, argument injection lets them break out entirely. Avoid wildcards in command specs. Be explicit. This is precisely the kind of subtle hole AI is good at spotting.

Let AI audit sudoers, verify with visudo

Paste your sudoers and drop-ins (scrub usernames if sensitive) and ask:

“Audit this sudoers config for privilege-escalation risks: wildcard command specs, NOPASSWD on dangerous binaries, editors or shells that allow breakout, and overly broad grants. Rank by severity and give the least-privilege rewrite for each.”

The model reliably flags NOPASSWD: ALL, a sudo vi that shells out, or tcpdump/find grants that allow arbitrary command execution. I keep this in my prompt library.

Then verify any rewrite it gives you:

sudo visudo -c

That checks all sudoers files for syntax. Never paste an AI-generated sudoers rewrite in and save without visudo -c confirming it parses — a confident-but-wrong line here costs you root.

The breakout binaries to never grant casually

Some commands, when run via sudo, let a user escape to a root shell: vi/vim, less, man, find -exec, awk, tcpdump -z, nmap (interactive), and anything with a shell escape. The GTFOBins project catalogs these. If you must grant one, sandbox it hard or reconsider — ask AI “does granting sudo find allow privilege escalation?” and it’ll explain the -exec breakout.

The reason these are so dangerous is that the escalation isn’t obvious from the sudoers line. deploy ALL=(ALL) NOPASSWD: /usr/bin/find looks like you scoped them to one harmless utility. But sudo find . -exec /bin/sh \; drops them straight into a root shell, because find runs its -exec payload with sudo’s privileges. The same trap applies to any tool that can spawn a subprocess or shell out — pagers, editors, interpreters. When in doubt, assume a utility can break out and check GTFOBins before you write the grant.

Audit who can do what

Periodically, confirm a user’s effective privileges rather than reading the raw file in your head:

sudo -l -U deploy

That lists exactly what deploy may run via sudo, resolving groups and includes — the same “trust the effective config, not the source file” principle that applies across Linux security work.

The takeaway

Read permissions owner-first, respect the special bits, and grant sudo as narrowly as the task allows — explicit commands, no wildcards, managed by group. Always use visudo, keep a root session open, and let AI audit for escalation paths while you verify with visudo -c. Least privilege isn’t bureaucracy; it’s the difference between a contained mistake and a compromised host.

AI permission audits are assistive. Verify every sudoers change with visudo -c and a held-open root session before trusting it.