Sudo In Linux — A Lot More Than An Elevated Permissions Tool

When in need of running a process with elevated privileges, there are a three main solutions. Firstly, you can login as root, but this can only be done with the root password and still carries some security concerns. Secondly, you can use su to run a single command as root, still, this requires the root password. Lastly, there’s sudo, if improperly configured, it is a security nightmare, but if done properly, which is very easy, it can maintain a secure system while allowing flexibility in day to day operations.

The first step to understanding the power and flexibility of sudo is in understand the aliases.

User Alias – This is exactly as it sounds. These are aliases for users or groups of users. They aren’t as common, though, as system groups are typically used instead.

Command Alias – The command aliases are commands or groups of commands.

Host Alias – The host aliases are typically the more difficult concept to understand, especially since the sudo configuration only applies to the local system of the user. The sudo configuration is intended to be distributed to all systems for convenience. Being the relatively small text file that it is, it’s a very easily accomplished task, especially when using a system such at Puppet or Chef. The host aliases then refer to hosts or groups of hosts, the given rules are determined by the alias that the host is a part of.

Run As Alias – These are for specifying users or groups of users as target privileges for the execution of tasks. For example, giving privileges of the database administrative user.

Using these aliases, a very powerful, yet flexible, security model can be created. The best part is that this single file can be distributed across multiple machines and provide certain privileges to certain users on each. Furthermore, it is even more powerful because sudo is available on not only Linux, but several other UNIX and UNIX-like operating systems, meaning a well-written sudo configuration can be cross-platform as well.

All sudo configuration are made in the sudoers configuration file, typically homed in /etc/ on most Linux distributions. You can start editing the file using whichever editor you prefer, or you can issue the command:

From here we can start off by making a User Alias by using the User_Alias directive:

Now, we’ll create a Command Alias to define the commands that the DBADMIN group is permitted to executed using the Cmnd_Alias directive:

Next, we’ll create a Host Alias for a single server with the Host_Alias directive:

Note that the Host Alias can be specified using an IP as well.

And, lastly, we’ll create a Run As Alias using the Runas_Alias directive:

Finally, we have everything in place to create a rule, but first, we’ll need to review the sudoers rule syntax. The default sudoers file has a line in it pertaining to the root user. The root user already has complete access to the system, so the default sudo configuration does nothing to impede that, even out of the box. When looking though the default configuration you’ll find the below line.

The sudoers file syntax is a little bit esoteric, but we’ll clear that up. First, it’s obvious that this line defines a rule for the root user given that it starts with ‘root’, this is where we would put our User Alias or, as is the case for root, a single system user. Note that it can also be a system group as well, though it must be prepended with a ‘%’. The second piece of information is the ‘ALL’, this is the location or host identifier, we can, again, put a single host, or we can use one of our Host Aliases. Next, there is the equals sign, this delimits the rule itself and who it applies to. Now, we have ‘(ALL)’ which is a little funny looking because it’s in parenthesis. This item indicates who the command can be run as, either a single system user or group or our Run As Alias. Lastly, we have the command identifier where we can place a single command, a list of commands, or our Command Alias. Let’s construct a rule, now.

It’s as easy as that. By mixing these concepts and applying them thoughtfully, a secure model for system administration can be achieved in a straightforward way, across multiple systems, and even multiple platforms. One note of high importance, though, is that sudo will use the last match it finds in the sudoers configuration file.

There is much more functionality to sudo beyond what has been outlined here, including rules based on command parameters and the “!” (NOT) modifier. Although, the sudo philosophy is never to implicitly allow, but to explicitly allow and implicitly deny. That is, only give explicit permission to perform a task, but do not make an explicit rule denying a permission because it becomes easily circumvented.

Did we miss any big features of sudo? Let us know in the comments below.

Also Read: Your Ubuntu Linux Terminal Experience Is About To Get A Whole Lot Better