Understand Sudo in Linux

Till now you have learnt how to manage access using file permissions. These types of permissions are classified into Discretionary Access Control (DAC) or user dictated access control.

There are basically two ways, to impersonate as a user and run commands on behalf of them. The straightforward one is su. It requires you to know the password of the target user and then on success, it will run the command

$ su amit -c id
Password:                       # entered wrong password
su: Authentication failure
$ su amit -c id
Password:                       # entered correct password
uid=1001(amit) gid=1001(amit) groups=1001(amit)

After release of sudo the above way is the last thing any user will do (I am one of them). Sudo can be classified into Mandatory Access Control (MAC) where the sysadmin has to manage a config file or policies for managing user access.

In this post, I will be discussing sudo in detail and in a later post, I will discuss the misconfigurations with sudo that could lead to privilege escalation

What is sudo anyway, and Why is it used?

Your passwords are your private property and you don't want to share them with others unless someone steals from you. In su you are obliged to share the password to run the commands.

Sudo is originally a UNIX utility release around 1980 (11 years before the Linux release) where sysadmin has to manage the /etc/sudoers file or files in /etc/sudoers.d/ directory to configure the permissions for the user. It means (superuser do) and it is used to define "which user/group can do what and on behalf of whom (by default its root) and how"

In sudo, you can not only provide the "run as" property for a user but also restrict which command can be executed with or without a password. If in sudoers file "run as" with password is configured, the user will be prompted to enter the password of their account rather than the target user password. Another feature is that unlike su, once you have successfully authenticated sudo access, it will cache "right to elevate" for your account rather than storing password so you can run the command as another user without actually entering the password unless the timeout and the NOPASSWD an option is not configured

Understand Sudoers File Format

The base file of checking sudo permissions is /etc/sudoers if you can include other the configurations from the files also using @includedir /etc/sudoers.d directive. It allows you to configure access for both groups and users using their ID or alias (

Formats of user and group as follows

Jonas  ALL=(ALL:ALL) ALL
#1001 ALL=(ALL:ALL) ALL

%developer  ALL=(ALL:ALL) ALL
#%2020 ALL=(ALL:ALL) ALL

The generic representation of the above configs would look like

<user/group list> (<host list> or ALL) = [<runas-user:runas-group>] [<tag list>] (<command list> or ALL)

Fields enclose in parenthesis ( and ) are required or pass ALL, and the fields in square bracket [ and ] are optional. If <runas-user:runas-group> is missing, it will be considered as (ALL:ALL) by default and <tag-list> will be ignored if not passed  

List of all tags are specified in Tag_Spec:– here

Sudo in Action

To run the command with sudo configured elevated privileges, add sudo in front of your normal command. For instance, you want to elevate the id command with sudo, the new command will look like sudo id

$ id
uid=1001(amit) gid=1001(amit) groups=1001(amit)
$ sudo id
[sudo] password for amit:
uid=0(root) gid=0(root) groups=0(root)
$ sudo id         # right to elevate is reused this time
uid=0(root) gid=0(root) groups=0(root)

Let's now allow user amit to execute ALL commands on behalf of user terabyte and any group also don't require a password for this action. The configuration for the above actions will look like

amit ALL=(terabyte) NOPASSWD: ALL

$ sudo id
[sudo] password for amit: 
Sorry, user amit is not allowed to execute '/usr/bin/id' as root on h3ll.
$ sudo -u terabyte id
uid=1000(terabyte) gid=1000(terabyte) groups=1000(terabyte)

In the first case, sudo was successfully authenticated but the configuration to run as root was not found in the sudoers config. In the second case, sudo used the same right to elevate because it was accessed before timeout and configuration to run as a terabyte user

To check what command user can run with sudo and run as which user, use sudo -l command

$ sudo -l
Runas and Command-specific defaults for amit:
    Defaults!/etc/ctdb/statd-callout !requiretty

User amit may run the following commands on h3ll:
    (terabyte) NOPASSWD: /bin/bash

As you check in this case, user amit can run command /bin/bash as terabyte user without entering any password