Skip to main content

Sudo explained

· 4 min read

Preface

At some point of my career, I wanted to land a job as a Junior SOC Engineer. To my surprise, I found myself struggling with technical interviews, even when asked relatively straightforward questions.

For instance, one question was, "What is sudo and how does it work?"

sudo in simple words

Apparently, anyone who has worked with Linux has used sudo. This program temporarily elevates a user's privileges to execute specific commands by validating the user's permissions in the sudoers file.

The definition

info

Sudo (su “do”) allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments. The basic philosophy is to give as few privileges as possible but still allow people to get their work done.

Example of use

Ordinary users cannot read the file /etc/shadow. Attempting to view it without sudo will result in a permission error:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Using sudo (assuming that this user is in the sudoers file) can grant the user permission to execute this command:

$ sudo cat /etc/shadow
[sudo] password for user:

root::18295:0:99999:7:::
daemon::18295:0:99999:7:::
bin:*:18295:0:99999:7:::
...

Now you have been granted the appropriate permissions and you can view the /etc/shadow file. But wait, what exactly just happened?

sudo command in more depth

Here are the main steps that sudo as a program does:

  1. Session Cache: Checks for cached credentials for already open sudo session.
  2. Password Prompt: Requests user's password if not found in cache previously.
  3. Authentication: Uses system's PAM (Pluggable Authentication Modules) to verify user's password.
  4. Privilege Check: Checks sudoers file for permissions.
  5. Command Execution: Runs command if authorized.
  6. Logging: Records the event.

There's a catch here: How does sudo checked the /etc/sudoers file, given that only root has the permissions to read this file??

Here comes the SUID bit.

The Power of the SUID Bit

When you look at sudo's binary file permissions, you'll see:

$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root [size] [date] usr/bin/sudo

That curious 's' is the SUID (Set User ID) bit. With this flag in permissions, a program runs with privileges of its owner regardless of the invoking user. In this respect, sudo is always executed by root and therefore can access the protected files such /etc/sudoers or /etc/shadow.

Did you know?

tip

sudo is not a proprietary OS utility; it's an open-source and continuously updated program. A look at its repository reveals consistent updates, under the dedicated supervision of Todd C. Miller. As of now, the latest stable version is 1.9.17p2, released on July 26, 2025. More info on the official site.

Logging for sudo

Every time sudo is invoked, it leaves a trail. These logs provide valuable insights, especially when auditing system access or investigating potential breaches. For Debian/Ubuntu you can see the logs in /var/log/auth.log file. To filter out the noise, use the grep command:

grep sudo /var/log/auth.log

In Conclusion

When preparing for a SOC or Cyber Security Engineer interview, understand that sudo is a Set User ID binary program that is always executed by root user.

Essential practices include:

  1. Control the sudoers file to ensure it follows the principle of least privilege.
  2. Limit user commands in sudoers to minimize potential damage in case some of your accounts get compromised.
  3. Consider monitoring sudo logs.
  4. Have an incident response plan in case of sudo misuse or compromise.
  5. Keep sudo updated to protect against known vulnerabilities.