Everyone with more than 10 minutes of Linux experience has learned to prefix their commands with SUDO to elevate their privileges to install packets, configure services and manipulate files owned by others.

To comply with the principle of least privilege, it's a bad practice that every user has root-level permission if they need more permissions than just their basic user permissions.

In this article, I will explain how SUDO roles can be used for granular privilege escalation. For example, we can limit the web administrator that only needs to reset the web server and PHP to only run the commands they need as SUDO.

Every line in the sudoers file is a SUDO role and has the following structure

The role line has four fields. The user field, the host field, run-as, and command.

The SUDO role starts by defining what user or group the role affects. The difference between a user and a group is that groups are prefixed with %.

The host field defines what host the role applies to. This might seem strange in a single-host environment, but the sudo file could be stored in an Active Directory-like LDAP environment such as RedHat FreeIPA and accessed remotely. If the host field is set to ALL the role applies to all hosts.

The run-as field limits who the user can impersonate using the sudo command. If ALL is set, the user can impersonate everyone, even the root user.

The command field lists the commands the user can run using the sudo command. In some situations, like when running webhooks connected to git repositories, it could be a good idea to limit the webhook user to only be able to restart the updated service. Another example is when you want a web developer to be able to restart services like a web server, PHP-fpm, and database but not be able to install software packages or do anything else that requires root-level privileges.