Sudoers Safe Defaults
Why Sudo Design Matters in Production
Sudo is not just a convenience tool. It is a controlled privilege escalation mechanism. Improper sudo configuration turns your server into a shared root shell. Production systems must treat sudo rules as security policy, not shortcuts.
Never Edit /etc/sudoers Directly
Always use:
visudo
Better practice:
/etc/sudoers.d/
Create separate policy files:
/etc/sudoers.d/deploy /etc/sudoers.d/ops
Principle of Least Privilege
Instead of giving full root access:
alice ALL=(ALL) ALL
Restrict commands:
alice ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp
Now Alice cannot run arbitrary commands as root.
Command Whitelisting Strategy
Allow only the exact binary paths. Avoid wildcards like:
/usr/bin/*
That defeats the purpose of restriction.
Deploy User Pattern
Production-safe deployment model:
- deploy user owns release directory
- deploy can restart service
- deploy cannot modify system configuration
deploy ALL=(root) NOPASSWD: /bin/systemctl restart myapp
Password vs NOPASSWD
NOPASSWD increases automation simplicity but reduces friction barriers. Use it only for narrowly scoped commands. For interactive maintenance, require password confirmation.
Auditing Sudo Usage
Check logs:
journalctl -u sudo grep sudo /var/log/auth.log
Every sudo execution should be traceable.
Common Production Mistakes
- Giving full sudo to developers “temporarily”
- Using ALL=(ALL) ALL everywhere
- Not logging sudo usage
- Allowing shell escape commands
Shell Escape Risk
Some programs allow shell escape:
sudo vim :shell
This can lead to unrestricted root access. Be careful which commands you whitelist.
Mental Model
Sudo rules define your privilege boundaries. If a service or user is compromised, proper sudo restrictions prevent full system takeover.
Production Checklist
- Use sudoers.d instead of editing main file
- No broad ALL=(ALL) ALL entries
- Whitelist exact commands
- Audit logs enabled
- Deploy user cannot open root shell