Restricting User Permissions in Linux with sudoers

Permissions in Linux

Different permissions like read, write and execute exist for owner, group and other users/guest users. As the naming suggests, read allows read access, write allows write access and execute allows access to run the program. A combination of these permissions can be applied to any file or directory on a Linux system.

Conventional permission looks something like this:

-rw-r--r--

drw-r--r--

Another thing that applies to this is ownership. Files and directories can be owned by a group of users or a single user.

Typical ownership looks something like this:

root:root

The first word signifies the user who owns it, and the second word signifies the group that owns it. When a user is created, a group with the same name is also created; that is why it's possible to use the user's name to specify ownership in both user and group fields.

chmod and chown Commands

A file's read, write, and execute permission is set by the command chmod – short for changemode, and a file's ownership is set by the command chown – short for changeownership.

So, if I wanted to provide modification permissions to the owner and executable permissions to all other users, then I would do the following:

chmod  711

This command will allow complete access to the owner and only executable permission to users who don't own the file but are present in the group that has ownership over it. The command also grants executable permission to other users without affiliation with the file owner.

Here, if I wanted to provide ownership of the file to a specific user and a group, then,

chown rice:devs

This command will change ownership of the file to user rice, and the group devs will also have ownership over the file. Any user in the devs group will be able to access the file depending upon the file permissions set using chmod.

If we combine the two commands we just used, here's what the scenario would be like – User rice can modify and delete the file. Any user in the devs group can only execute the file, and other users who are neither owners nor are in the ownership group will only be able to execute the file.

This is just a hypothetical example. In practice, it's not a good idea to allow executable permissions to all users in the system. It's best to narrow down permission to select users who need it.

SUDO – Admins Performing Certain Actions Without Hiccups

The sudo command can now come into play. SUDO is short for SUPERUSER DO, meaning do anything as the superuser (root) user.

If you are new to sudo, it is a command line tool on most Unix OSs that allows a user or group of users to run commands as another user.

A good feature of sudo is its ability to leave a trail of logs. When you execute a command with sudo, it's automatically logged into the audit.log file. We can easily check who ran what command at what time and on which date.

A user can be provided access to sudo by adding them to the sudo group. The users can perform all operations that can be performed by a root user. They can also switch to the root user themselves or make their user accounts a superuser and remove the existing superuser. This opens up many avenues of misuse.

Sudo can be enhanced using the sudoers plug-in. It's a security policy plug-in installed by default in a Unix system. It can be used to determine access permissions for specific files when using sudo.

When creating a sudoers policy, we want the user or group to have the least amount of privilege possible. Thinking that a host can be locked down and work can still be done is wishful thinking. There always will be something that requires more permission than necessary.

So now here's what we'll do,

We'll create a sudoers security policy configured by a file and determine what permissions users have when they invoke the sudo command. This policy will allow members of the devs group to use the sudo command to start, stop, restart, and edit the nginx configuration.

Configuring SUDO

The sudoers file is where we configure security policies (for users and groups) that invoke the sudo command. This type of security file is composed of sections called Defaults, User Specifications, and Aliases. A sudoers file is read from the top down, and since rules are applied in that order, the last matching rule always wins.

The Defaults syntax allows you to override some sudoers options at runtime, such as setting environment variables that users have access to when they run sudo.

The User Specifications section determines which commands users can run and on which host they can run them. For example, the user Rice can be given permission to run, start, and restart specific services on the web server host.

The Aliases syntax references other objects inside the file, which is useful for keeping the configuration concise.

The four aliases you can mix and match are as follows:

1. Host_Alias – A host or a group of hosts
2. Runas_Alias – A list of users or groups a command can be run as
3. Cmnd_Alias – Specifies a command or multiple commands
4. User_Alias – A user or group of users

Provided below is an example sudoers file. Save it into a file called sudo.tmp and try to verify the file. If all goes well, we will place it in its relevant directory.

# Command alias
Cmnd_Alias      START_WEB    = /bin/systemctl start nginx
Cmnd_Alias      STOP_WEB     = /bin/systemctl stop nginx
Cmnd_Alias      RESTART_WEB  = /bin/systemctl restart nginx

# Host Alias
Host_Alias      LOCAL_VM = '192.168.1.5'
# User specification
%devs LOCAL_VM = (root) NOPASSWD: START_WEB, STOP_WEB, \
                       RESTART_WEB, \
                       sudoedit /etc/nginx/nginx.conf

For validation of the sudoers file, run the following command:

visudo -cf sudo.tmp

Once our validation passes, we can confidently place it in the systems' sudoers file, which can be accessed using the command visudo.

Example Scenario

The non-root user Rice will not be allowed to modify the nginx config by default, as it requires sudo permissions. They will be able to view the file but not modify it, but with the help of sudo, Rice will be able to modify the said file and also be able to stop, start and restart the nginx web server.

Make some changes to the nginx.conf file and save it using the command below.

sudoedit /etc/nginx/nginx.conf

Now restart the service using the command,

sudo systemctl restart nginx

The user Rice can also execute the following commands now.

sudo systemctl stop nginx
sudo systemctl start nginx

Finally, let's try to view the system's auth logs,

tail -f /var/log/auth.log

Access to view the logs will be denied to our user Rice.

System Auth Logs

As mentioned previously, one great feature of sudo is that it leaves behind an audit trail. The events in this trail are typically used in a monitoring framework or when doing forensics during an incident response. No matter what, you should make sure the audit data is in an accessible area so you can review it.

If you followed along with the testing in this chapter, you ran the sudo command four different times. Those events were captured in the /var/log/auth.log file, so let’s explore some of the log lines from those sudo commands.

I have listed a few that were generated here on my system. However, feel free to explore the log file in more depth.

Viewing the Logs

The lines in auth.log provide a bit of information. We'll focus on the ones we need but mostly on the date, time, user, and command columns.

You can see that Rice invoked sudo on 22 September for editing the nginx configuration file and restarting the nginx service.

Sep 22 15:42:25 ubuntu-focal sudo:   rice : TTY=pts/0 ; PWD=/home/rice ; USER=root ; COMMAND=sudoedit /etc/nginx/nginx.conf

Sep 22 15:42:58 ubuntu-focal sudo:   rice : TTY=pts/0 ; PWD=/home/rice ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx

Again, on the same date at 15:43:14, Rice tried to view the auth logs using the command /usr/bin/tail -f /var/log/auth.log but was denied.

Sep 22 15:43:14 ubuntu-focal sudo:   rice : command not allowed ; TTY=pts/0 ; PWD=/home/rice ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log

Generally, this type of line should generate alerts in our monitoring/logging system, as this could be a malicious actor trying to access our system.

So this is how we can keep track of the commands executed by a user using sudo.

In This Blog,

we learned the importance of letting users run commands with elevated privileges. Using the sudo command and sudoers file, we learned to restrict command access and sudo access logging.

Please comment below if you have any queries, I periodically try to update my articles to ensure legibility.