find sudo rules that let you run as root, no password
sudo -lthe one command that tells on your sudoers file
you've probably typed sudo a hundred times without ever asking "wait, what am i actually allowed to do here." there's a command that answers that in one shot, and it's built into every linux box that has sudo installed. no scanning, no tools, no nonsense.
sudo -lthat's it. run it on your own machine right now. what comes back might surprise you, and if you're a sysadmin, it might make you a little uncomfortable, in a good "glad i checked" kind of way.
what sudo -l actually shows you
the -l flag means "list." sudo looks at /etc/sudoers and any files dropped into /etc/sudoers.d/, figures out which rules apply to your user or your group, and prints them out. this includes:
which commands you can run as root or another user. maybe it's everything, maybe it's one script.
whether you need a password to do it. this is the part people miss. a rule with NOPASSWD in it means anyone with your session, your ssh key, or your unlocked terminal can run that command as root instantly. no prompt, no friction, no second factor.
if you see a line like this in the output:
(ALL) NOPASSWD: /opt/scripts/backup.shthat means your account can run backup.sh as any user, including root, and sudo won't even ask for a password first.
why this matters even if you trust yourself
the point of checking this on your own systems isn't paranoia about yourself, it's about everyone downstream of a mistake. think about who else could end up in that shell: a script that got compromised through a bad dependency, a coworker who borrowed your terminal for "one quick thing," an attacker who phished your session cookie or ssh agent. once someone has your user context, sudo -l is one of the first commands they'll run too, because it tells them exactly what free root access looks like on your box.
a NOPASSWD rule on a broad command is basically a root shell with extra steps. a NOPASSWD rule on a narrow, well-written script is much safer, but only if that script can't be abused to do something it wasn't meant to do.
the real danger: scripts that aren't as locked down as they look
a lot of admins think "i only gave NOPASSWD access to one specific script, so we're fine." but if that script accepts arguments, reads environment variables, or calls other commands without full paths, it can sometimes be tricked into running arbitrary things as root. that's a defensive rabbit hole on its own, but the short version is: any NOPASSWD entry deserves a second look at what the target file actually does, not just what it's named.
check the permissions on the script itself too:
ls -l /opt/scripts/backup.shif a non-root user can edit that file, and root or a NOPASSWD rule can execute it, you've got a privilege escalation path sitting right there in plain sight.
how to lock this down on your own systems
first, audit before you edit. run sudo -l for every user and service account you manage, not just yourself. keep a list of every NOPASSWD entry you find.
edit sudoers safely, always with:
sudo visudothis checks your syntax before saving, so you don't lock yourself out of sudo entirely.
remove NOPASSWD wherever it isn't truly necessary. it exists for automation, not convenience. if a human is typing the command, they can type a password.
for scripts that genuinely need passwordless root access, like a monitoring agent or a backup job, lock the file down hard: root ownership, no group or world write access, and full paths inside the script for every command it calls.
finally, log it. sudo already logs to /var/log/auth.log or your system journal, so make sure something is actually reading those logs, whether that's you, a siem, or a simple alert on sudo usage outside business hours.
the takeaway
sudo -l is a two-second command that shows you exactly where the soft spots are in your own privilege setup. run it on everything you manage, question every NOPASSWD line you find, and lock the scripts behind them down like they're the front door, because functionally, they are.