DevTools Hub

Search tools

Search for a developer tool

Linux Security

Sudoers File Analyzer

Analyze a sudoers file for NOPASSWD: ALL grants, wildcards, and risky unrestricted binaries.

Part of the Linux Security Toolkit

Paste a /etc/sudoers file or a sudoers.d snippet. Aliases aren't expanded — each command spec is analyzed as written.

Findings (4)
Line 7: "backup ALL" is granted NOPASSWD: ALL as (ALL) — unrestricted, passwordless access to run anything.
Line 4: "root ALL" is granted ALL commands as (ALL:ALL) — full root access, gated only by a password prompt. Confirm this breadth is actually needed.
Line 5: "%wheel ALL" is granted ALL commands as (ALL) — full root access, gated only by a password prompt. Confirm this breadth is actually needed.
Line 8: "vim" is commonly documented (see GTFOBins) as able to spawn a shell or read/write arbitrary files when run without argument restrictions — worth reviewing whether granting it unrestricted via sudo is actually necessary here.
Parsed lines
  • Defaults env_resetdefaults
  • Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"defaults
  • root ALL=(ALL:ALL) ALLrule
  • %wheel ALL=(ALL) ALLrule
  • deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapprule
  • backup ALL=(ALL) NOPASSWD: ALLrule
  • alice ALL=(ALL) /usr/bin/vimrule

What this does

Analyzes a /etc/sudoers file or a sudoers.d snippet, entirely in your browser, for the specific patterns that turn sudo access into a privilege-escalation path: NOPASSWD: ALL grants, dangerous Defaults overrides (like !authenticate or a session timeout that never expires), wildcards in command specifications, and well-documented GTFOBins-style binaries — vim, find, python, and similar — granted without any restriction.

Why this matters for least privilege

sudo is the single most common way least privilege actually gets implemented — or quietly undone — on a Linux server. A grant that looks narrow at a glance, alice ALL=(ALL) /usr/bin/vim, can amount to an unrestricted root shell in practice, since vim can spawn one from inside its own interface. This tool exists to surface exactly that gap between what a sudoers line looks like it grants and what it actually grants.

What this doesn't do

This isn't a syntax validator — run visudo -c on the real file for that, and always edit sudoers only through visudo so a syntax error can't silently leave the file unusable. It also doesn't expand User_Alias, Cmnd_Alias, or Host_Alias definitions — each command specification is analyzed exactly as written.

FAQ

What does this tool actually check?

Dangerous Defaults overrides (like disabling authentication or letting a sudo session never expire), NOPASSWD: ALL grants, plain ALL command grants, wildcards in command paths, and well-known GTFOBins-style binaries (vim, find, python, and similar) granted without restriction — the specific patterns that turn a working sudo configuration into a privilege-escalation path.

Does this tool expand User_Alias, Cmnd_Alias, or Host_Alias definitions?

No — each command specification is analyzed exactly as written. If a risky grant is hidden behind an alias name rather than spelled out directly, this tool can identify the alias definition line but won't automatically trace where that alias is later used in a rule.

Is a plain ALL grant always a problem?

Not necessarily — a system administrator legitimately needing full root access via sudo is completely normal. It's flagged as worth a second look specifically to make the breadth of the grant visible, not because unrestricted access is inherently wrong for the account that actually needs it.

Why are vim, find, and similar tools flagged when granted through sudo?

Each is documented (see GTFOBins) as capable of spawning an interactive shell or reading/writing arbitrary files from within its own interface — meaning granting one of them unrestricted via sudo can amount to granting a full root shell, even though the sudoers line itself only names one seemingly narrow binary.

Can I validate my sudoers file's syntax with visudo instead?

Yes, and you should — visudo -c on the actual server is the authoritative syntax check and the only way to be certain a file is safe to install. This tool complements that by focusing on security implications a syntax checker doesn't evaluate, not by replacing it.

Try it yourself

For the full reasoning behind sudo hygiene and how it fits into least privilege, see Sudoers File Explained or the complete picture in Linux Security.

Related tools