Hey there, fellow DevOps engineers!

Let's talk about a few bad habits we sometimes fall into when using sudo and why we need to kick them. We've all been there—needing to run a bunch of commands as root and opting for a shortcut. But these shortcuts can introduce security risks that are tough to track and manage.

The good news is, there's a better, safer way to do things.

The three bad uses of sudo

Are you using any of these quick and dirty tricks to get into the root shell:

• sudo su
• sudo -i
• sudo bash

Then, you are putting your beloved Tux 🐧 at risk.

Why?

These commands effectively give you an unrestricted root shell, and once you're in that shell, you can run any command you want without the sudo prefix.

This leads to several problems:

• Lack of accountability: When you run a command like sudo rm -rf / directly, it's logged by sudo and can be audited later. If you get a root shell with sudo su and then run rm -rf /, the sudo log will only show that you ran sudo su, not the destructive command you executed afterward. This makes it impossible to trace exactly what happened, which is a nightmare for incident response and security audits.
• Privilege escalation risk: With a root shell, a single misplaced command or a malicious script can have catastrophic consequences. You're not just running a single command with elevated privileges; you're operating as the superuser for an extended period, which increases the likelihood of human error or a security breach being exploited.
• Security logging bypass: The purpose of sudo is to provide a granular, auditable way to grant specific users access to specific commands. By getting a full root shell, you're bypassing that entire logging and control mechanism. It's like having a security camera at the front door but then leaving the back door wide open.

sudo was not created to brake your bad habits

Now, you may be wandering why sudo is allowing this bad uses. Shouldn't those be blocked by sudo itself.

The fact is sudo was not meant for such purposes. The intention of the creators of sudo was to create a mechanism that allow sysadmins to assume admin privileges without sharing the root credentials.

sudo fulfills that requirement very well. But, due to the nature sudo itself, these commands like sudo su are allowed as by products. There is no effective way to block such commands for an admin user.

If an administrator is granted the ability to run sudo, they can use it to execute any command they want as root, including shells like bash or commands like su. Blocking a specific command like sudo su would be trivial for a determined admin to bypass by simply running sudo bash or even a more obscure shell command.

The security boundary isn't the command itself; it's the administrator's trust level.

The correct and safe way to use sudo

The best practice is to always use sudo <command> for every command that requires elevated privileges.

• Auditability: Each command you run with sudo is logged, providing a clear and complete record of what was done. This is invaluable for troubleshooting, security audits, and ensuring compliance.
• Principle of least privilege: By using sudo <command>, you're only granting elevated privileges for that single command. This minimizes the risk of accidental damage and limits the scope of any potential security vulnerabilities.
• Improved security: This method forces you to be more deliberate about your actions. You have to consciously type sudo for each command, which acts as a small mental check, reducing the chance of running a destructive command by mistake.

To further illustrate why these commands pose similar risks, here's a table outlining their key differences:

In the world of DevOps, where security and accountability are paramount, making this a habit is non-negotiable. It protects you, your team, and your infrastructure by providing a clear, auditable trail of all administrative actions. So, let's make a pact: no more sudo su or sudo -i.

Let's stick to the secure and auditable sudo <command> pattern.