The first time installing Ubuntu on my desktop computer in 2005, I was confused by the absence of the root user.

Every other Linux distro at the time, had a root user I can log in with. Ubuntu did not. Instead, Ubuntu used sudo.

Literally, I just prefixed every command with sudo and was happy about it. But the significance of sudo, I realized only many years later, when working on production Linux servers. At the same time, I also realized that sudo is widely misused (or underused).

I believe the DevOps engineers who misuse sudo have a notion that sudo takes their admin power away from them.

it's not so.

What is sudo?

sudo stands for Superuser Do.

sudo allows a permitted user to execute a command as root (or superuser). Think of it as a controlled gateway to administrative powers. Instead of directly logging in as the all-powerful root user, you use sudo to temporarily assume those privileges for a specific command.

sudo has been a part of Linux OS from 1990s. But it was Ubuntu that played a significant role in popularizing sudo around 2004 by locking out the root account by default and granting sudo privilege to the first user created on a new Ubuntu installation.

Since then, other Linux distros also have adopted the same approach.

Why you should use sudo (No matter whether you are the admin or not)

We DevOps engineers want all the power in the world (I mean all the privilege in Linux boxes).

Then, we find sudo standing between us and that ultimate power. So, here's what some (even experienced) DevOps engineers do. They work around it by permitting SSH access via root user.

But let me tell you. sudo exists for a reason. And sudo does not take power away from you. And sudo can protect you and your beloved Tux in several ways:

#1: Reduce the risk of accidental risky commands

You login to a production web server at 03:00 in the morning to troubleshoot 'website unresponsive' problem.

Accidentally you run rm -rf / 😱😱😱

Your entire disk gets wiped out. And did you know? Even after this Ubuntu will be happily working until you reboot the box

It has happened before and there's nothing to say that it won't happen again.

We're all human, and mistakes happen, especially when dealing with complex matters. Running commands directly as root increases the potential for catastrophic errors due to a simple typo or oversight. A misplaced rm -rf / as root can wipe out an entire system in seconds!

sudo mitigates this risk by:

• Requiring Explicit Action: You have to consciously prefix a command with sudo and often enter your own user password (depending on the sudoers configuration). This extra step can serve as a mental checkpoint, making you think twice before executing a potentially dangerous command.
• Limiting Scope: You can configure sudo to allow users to run only specific commands or sets of commands with elevated privileges. This principle of least privilege ensures that even if a mistake is made with sudo, its impact is limited to the allowed actions.

#2: Share root privileges responsibly across team members (Without sharing the root password!)

In a multi-user environment (a DevOps team maintaining Linux servers), accountability matters. (No matter how much you know your colleagues)

Sharing the root password across multiple engineers is a recipe for disaster. It creates a single point of failure, makes it impossible to track who made which changes, and significantly increases the risk of unauthorized access.

sudo provides a much more elegant solution. You can grant specific users or groups the ability to run certain commands with root privileges without ever revealing the root password itself. This allows your team to perform necessary administrative tasks while maintaining:

• Accountability: Every sudo command is logged, typically with the username of the invoking user. This creates an auditable trail, allowing you to track who executed which privileged commands and when. This is invaluable for troubleshooting and security investigations.
• Security: By not sharing the root password, you significantly reduce the risk of it falling into the wrong hands, whether accidentally or maliciously.

#3: Enhance protection against malicious software

Yes. sudo can protect you against malicious software.

Imagine someone hijacked your SSH session (yes, this is possible) and placed a malicious shell script and created a cronjob to run it at 11.00 PM while you are asleep.

If you have properly set up sudo (with password authentication) the malicious shell script only has access to your home directory. Provided basic security hygienie is in place, the blast radius is significantly minimized.

While sudo isn't a silver bullet against all malware, it significantly enhances your system's security posture:

• Limiting the Blast Radius: If a piece of malware manages to compromise a regular user account, its capabilities are limited by the permissions of that user. It cannot directly make system-wide changes or install rootkits without somehow gaining root privileges. sudo acts as a barrier, requiring the malware to either exploit a sudo vulnerability (which are rare) or trick a legitimate user into running a sudo command.
• The Need for Explicit Escalation: Malware running under a regular user account cannot silently gain root access. It would need to somehow trigger a sudo prompt and obtain a valid password. This makes it much harder for malware to gain full control of the system.

How to use sudo effectively

Using sudo effectively is simple—all Linux distros now includes sudo, and have their default settings optimized for secure login. Nevertheless, check out these steps to make sure you use sudo as intended.

Step #1: Disable direct root login

Edit your SSH server configuration file (usually /etc/ssh/sshd_config) and ensure the following line is set:

PermitRootLogin no

After making this change, restart your SSH service.

This prevents anyone using root account log in to the Linux OS via SSH. It forces everyone in the team to go through sudo, ensuring accountability and control.

Step #2: Create individual accounts for all users

In the 90s, Linux systems were shared among multiple users for computing tasks by creating individual user accounts on the bare-metal server.

Thanks to popularization of resource sharing mechanisms like containerization, access to Linux servers is now limited to DevOps team members. Yet, you must create individual user accounts for those team members who access Linux servers for administrative purposes. It's crucial for tracking actions via sudo logs.

Avoid generic shared accounts whenever possible.

Step #3. Leverage the power of the sudoers configuration

The /etc/sudoers file is where you define who can run which commands as which users (including root) using sudo. Never edit this file directly with a text editor. Always use the visudo command. visudo locks the file to prevent corruption and performs syntax checking before saving.

Here are some common sudoers configurations:

• Allow a user to run all commands as root (use with caution):

  your_username ALL=(ALL) ALL

• Allow a user to run specific commands as root without a password:

  your_username ALL=(ALL) NOPASSWD: /sbin/reboot, /sbin/shutdown

• Allow a group of users to run specific commands as a specific user:

  %webadmins ALL=(www-data) /usr/sbin/service apache2 restart

Key Considerations for sudoers:

• Principle of Least Privilege: Grant only the necessary privileges to each user or group. Avoid giving blanket root access unless absolutely required.
• Specific Commands: Instead of allowing all commands, specify the exact commands users are authorized to run.
• No Password (NOPASSWD): Use this option sparingly and only for commands that are frequently executed and deemed safe. Be aware of the security implications.
• Comments: Document your sudoers file clearly to explain the purpose of each entry.

Embrace sudo for secure DevOps practices

In the dynamic landscape of DevOps, especially when managing infrastructure that might be serving users across the globe, security and accountability are non-negotiable.

sudo provides a robust and flexible mechanism to manage privileged access, empowering your team while minimizing risks. By understanding its principles and implementing it correctly, you can build a more secure, auditable, and efficient DevOps environment.

So, take the time to review your sudo configurations, educate your team on its importance, and make sudo a cornerstone of your secure DevOps practices. Your future self (and your security team!) will thank you.