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:
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:
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.
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:
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,
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
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.
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
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.
Defaults syntax allows you to override some sudoers options at runtime, such as setting environment variables that users have access to when they run
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.
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:
Host_Alias– A host or a group of hosts
Runas_Alias– A list of users or groups a command can be run as
Cmnd_Alias– Specifies a command or multiple commands
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.
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
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
restart the nginx web server.
Make some changes to the
nginx.conf file and save it using the command below.
Now restart the service using the command,
sudo systemctl restart nginx
The user Rice can also execute the following commands now.
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
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
You can see that Rice invoked sudo on 22 September for editing the nginx configuration file and restarting the nginx service.
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.
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.