As DevOps engineers we often work with elevated privileges in Linux.

The more privileges you have, more vulnerable you become. So, we need to take extra care to minimize these vulnerabilities.

Here are 7 bad practices of sudo usage in a DevOps context (with how you can do it better):

Bad practice #1: Granting NOPASSWD: ALL for automation accounts

While convenient for CI/CD pipelines and automation scripts, giving an automation user NOPASSWD: ALL in the sudoers file means that if that single account is compromised, an attacker gains immediate, unrestricted root access to any system where it's configured. This is a massive attack surface.

• Better Practice: Implement the principle of least privilege by defining specific, granular sudo rules for only the commands absolutely necessary for the automation task, ideally with NOPASSWD: only for those very few, specific commands.

Bad practice #2: Hardcoding passwords or secrets for sudo in scripts

Storing sudo passwords directly in scripts or configuration files (even if encrypted or base64 encoded) that automation tools use is a severe security flaw. Anyone who gains access to these scripts can quickly extract the credentials and escalate privileges.

• Better Practice: Use dedicated secret management solutions (e.g., HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets) to securely store and retrieve credentials, integrating them with your automation tools.

Bad practice #3: Using sudo -i or sudo bash in automation scripts

As discussed, sudo -i or sudo bash creates a persistent root shell. If an automation script unexpectedly fails or exits prematurely while in such a shell, it could leave a root-privileged session open, which a malicious actor could then exploit.

• Better Practice: Use sudo <command> for individual commands requiring elevated privileges. For sequences of commands, wrap them in a dedicated, secure shell script and grant sudo access only to that specific script.

Bad practice #4: Inadequate sudo logging and monitoring

Failing to configure sudo to log all actions and not actively monitoring those logs means you lose crucial visibility. If a breach occurs or an unauthorized action is taken, you won't have an audit trail to determine what happened, who did it, and how to remediate.

• Better Practice: Ensure sudo logging is enabled (usually to /var/log/auth.log or a centralized SIEM system) and implement alerts for suspicious or unauthorized sudo attempts.

Bad practice #5: Broad sudo permissions for human users

Giving DevOps engineers, or even developers, ALL=(ALL) ALL access by default for their daily interactive use is an anti-pattern. This significantly increases the blast radius if their workstation or credentials are compromised.

• Better Practice: Define granular sudo access for human users based on their roles and responsibilities. Use command aliases and restrict access to only the necessary binaries and arguments. Regularly review and revoke unnecessary permissions.

Bad practice #6: Not periodically reviewing sudoers file configuration

Over time, sudoers files can become cluttered with outdated or overly permissive rules. Neglecting regular audits of these configurations can lead to stale access, where former employees or old automation accounts still have root access.

• Better Practice: Implement a regular review process for sudoers files, ideally as part of an infrastructure as code (IaC) solution, with version control and peer review for all changes.

Bad practice #7: Ignoring underlying vulnerabilities in sudo or related binaries

Relying solely on sudoers configurations without patching the sudo binary itself or other binaries that users can sudo to (like vim, find, less, etc.) can expose the system to privilege escalation. Attackers actively look for known vulnerabilities or misconfigurations in such binaries to escape sudo restrictions.

• Better Practice: Keep all system packages, including sudo, up-to-date with the latest security patches. Be aware of the "shell escape" features in common utilities and restrict access to them if users have sudo permissions to those specific tools.

---

Avoiding these bad practices. They look simple and are likely to get overlooked.

But, a vulnerability, however small can be exploited to create a catastrophic impact.