Linux Fundamentals: A to Z of a Sudoers File.
A comprehensive guide to Master Sudoers File.
What is a Sudoers File?
A Sudoers file is just like any other file on a Linux Operating System. But it plays a vital role in managing what a “User” or “Users in a Group” can do on the system.
Why the name Sudoers?
The word Sudo is the abbreviation of the term “Super User Do”. As it clearly suggests — it is just like telling the Kernel/OS “you have no choice, just do it!”. So the users with Sudo permission are called as Sudo Users. Management of all these sudo users is done through a file called as Sudoers File. This file also lives in the /etc directory just like any other configuration file.
Why Sudoers File?
A normal user on Linux will have many restrictions in the system. For example — the user won’t be able to start a service, change a config file or execute a script on the system by default. From a security perspective this looks perfect.
But, let us take an example of — you as a system admin have to manage all the users and their controls. You have a website hosted on Apache in one of your servers. You already have a Web-Admin to manage it. A user should be created for him on the Web-Server. This User should be allowed to do two things which a normal user cannot :
- Start/Restart Apache Service in case it stops.
- Edit the config file of Apache.
You have two user options by default :
- Root User which has got all the permissions on the system including Apache.
- A normal user, which by default won’t be able to Start a Service or edit any config files on the system.
This is when a sudoers file will come handy to you. In Sudoers file we can exactly define :
- Web-Admin user can only start Apache Service &
- He can only edit Apache Config file.
Playing with the Sudoers File
Enough theory, we’ll start doing the real stuff now. I will be explaining each section in Sudoers file with some examples. By default a Sudoers file looks like this —
Primarily we can see five sections in the file — the first three sections in the file are related to ALIAS of Host, User and Cmnd. We will talk about ALIAS later, first let us talk about the core section :
#User Privilege Specification
root ALL = (ALL:ALL) ALL
Note: ‘#’ indicates comment in the file, OS will ignore this line while executing.
Syntax : User <space> OnHost = (Runas-User:Group) <space> Commands
Example: root ALL = (ALL:ALL) ALL
Read it as — User Root can Run Any Command as Any User from Any Group on Any Host.
→ The first ALL is used to define HOSTS. We can define Hostname/Ip-Address instead of ALL. ALL means any host.
→ Second ALL : Third ALL is User:Group. Instead of ALL we can define User or User with the group like User:Group. ALL:ALL means All users and All groups.
→ Last ALL is the Command. Instead of ALL, we can define a command or set of commands. ALL means all commands.
To put it very simple, it is “who where = (as_whom) what”.
Note: Most of the people understand HOSTS as remote HOSTS. It is the LOCAL HOSTNAME/IP-ADDRESS. HOSTS field will be rarely used, if you want to know more about HOSTS in Sudoers please refer → https://www.sudo.ws/man/1.7.10/sudoers.man.html
Basically we can permit a user to do something in only two ways —
- Directly give him the permission to execute the command by modifying the permission of the file.
- Allow him to execute the command as an other user which already has the permission to execute this command.
In the Sudoers file we will be implementing the latter one.
We will use another example to clearly understand the fields in the syntax:
Example : sysadmin ALL = (root) /usr/bin/cat /etc/shadow
Read this as — User “sysadmin” can Run the command “/usr/bin/cat /etc/shadow” as ROOT user on all the HOSTS.
Here in the above example, in the command section — i have added something more than a command, this is to show the flexibility of Sudoers file. The part “/usr/bin/cat” is a binary executable or command used to view the contents of a file. The part “/etc/shadow” is a confidential file which stores passwords, so it means the user “sysadmin” can only run “/usr/bin/cat” on “/etc/shadow” file, if this user tries to view the contents of any other file which he has no read permissions on, he won’t be able to.
Syntax of Sudo command: sudo <command>
Example: sudo cat /etc/shadow
Now if the user “sysadmin” uses sudo before any command, OS will first ask him the USERs Password, verifies the password and then goes to Sudoers file and checks if he is allowed to issue this command as any user. If he is allowed — success, else it will report back one of these two things —
→ User is not in the Sudoers file. This incident will be reported.
Note : You can see this reported incident in /var/log/auth.log
→Sorry, user <username> is not allowed to execute <command> as <User> on <hostname>
Here, user webadmin is only allowed to run “cat /etc/shadow”. But he tried running ‘cat’ command on “/etc/gshadow” which is not allowed.
As we have got enough grip on the fields in the syntax of Sudoers file, let us move forward and understand other sections in the file. All the other sections will depend on the core section which we already discussed.
The next section is GROUP Section, which is
#Allow members of group sudo to execute any command
%sudo ALL = (ALL:ALL) ALL
Percentile symbol ‘%’ is used to represent a group in Sudoers File. All the fields and their functionalities in this section are exactly the same as discussed in the previous section — the user section. We can assign the same Sudo Privileges to a group instead of a user by specifying the group name — %<group name>. So all the members in the group will inherit the same privileges given to the group.
By default there exists a SUDO group defined in the Sudoers file. We can see these permissions are exactly the same as ROOT users permissions in the file. So if a user is a member of this SUDO group, he can execute all the commands that a ROOT user can execute.
Let us define a custom group and understand the syntax more clearly. Let us take the same old System Admin example to do so. Assume the no. of employees are more now, so the System Admins are 3 now. Each of these need the same exact permissions which we had given to the first System Admin. One thing we can do to achieve this is have three entries for all the three System Admins in the Sudoers file. If we go with this approach, we are insulting the capabilities of a Sudoers File.
The Best thing to do is, group all the three System Admins into a group named as ‘SystemAdminGroup’. We will define required permissions on this group with —
%SystemAdminGroup ALL = (root) /usr/bin/cat /etc/shadow
Now all the three admins can execute the Privileged Command. We did this in one go using the Group Definition.
Sudoers File is capable of making this whole process more efficient using various functionalities. The first three sections — ALIASES are used to achieve this. As the word already suggests, we use an ALIAS to something which we can use throughout the file, it’s just like a GLOBAL VARIABLE in a Script. How does this make the whole thing more efficient? We can define set of commands, hosts and users in one line, we assign this line to an ALIAS name, this alias will be used whenever and wherever needed without defining all the commands/hosts/users all over again.
I want to include one more ALIAS which is not listed in Sudoers file by default which is “Run_as ALIAS”. Now we have four ALIASES —
- User ALIAS as User_Alias
- Run-As ALIAS as Runas_Alias
- Host ALIAS as Host_Alias
- Command ALIAS as Cmnd_Alias
Note : Alias name should be defined in uppercase letters and can contain number, alphabet and underscore (_). Alias name must start with alphabet.
Let us understand each Alias by looking at the Syntax of it:
User ALIAS Syntax —
User_Alias <ALIAS Name> = <username>,<username>, <username>…
Example: User_Alias SYSADMINS = john,tim,tom
Usage: SYSADMINS ALL = (root) /usr/bin/cat /etc/shadow
If i want some set of sudo permissions defined for the users — john, tim and tom, I need not define it three times, instead i can define an Alias and use this Alias Name while delegating the sudo access to them.
Run As ALIAS Syntax —
Runas_Alias <ALIAS Name> =<username>,<username>,<username>…
Example: Runas_Alias MGRS = root,sradmin
Usage: systemadmin ALL = (MGRS) /usr/bin/cat /etc/shadow
If i want to define the set of users a user can run a command as, i can use Runas_Alias. Don’t get confused here, just remember the master mantra — who where = (as_whom) what. We are using an alias here to include no. of users in “as_whom” field.
Host ALIAS Syntax —
Host_Alias <ALIAS Name> =<hostname>,<hostname>
Host_Alias <ALIAS Name> =<ip/mask>,<ipnetwork>
Example: Host_Alias HOSTS = mylinux,salespc
Example: Host_Alias HOSTIPS = 172.17.103.0/255.255.255.0
Usage: systemadmin HOSTS = (root) /usr/bin/cat /etc/shadow
If i need to define set of hostnames, ip addresses or ip address range on which a user is allowed to issue the Privileged/Sudo commands, i can achieve this using Host Alias. Again, this part belongs to the “where” field in the Master Phrase.
Command ALIAS Syntax —
Cmnd_Alias <ALIAS Name> = <cmd1>,<cmd2>, <cmd3>…
Example: Cmnd_Alias SYSADMIN = /usr/sbin/apache2, /usr/bin/cat
Usage: systemadmin ALL = (root) SYSADMIN
If i need to permit a user to execute a set of commands as SUDO, i can define them under a Cmnd_Alias Section and use this ALIAS name while delegating the access. This part belongs to the “what” field in the Master Phrase.
NOPASSWD Mode:
This is one more special feature in Sudoers which will allow a User in Sudoers file to execute a privileged command without entering the password. This is very useful when running automated scripts in the system as a normal user, the script may have to execute a privileged command. But we already know what happens if any user uses SUDO, he will have to enter his password!
Remember that, even if it is a script or process, it should run AS A USER, it cannot run on its own.
All the automated scripts are not intelligent enough to enter password when prompted. But it is possible to auto-enter password. For time being let us not think about intelligent scripts. So to conclude, a privileged command can be used by a User without entering the password.
Example of a script needing NOPASSWD: Supervisor in Linux.We will discuss about Supervisor in another article.
Syntax : sysadmin ALL = (root) NOPASSWD : /usr/sbin/apache2
Parameter Exclusion in ALIASES
We can also add parameters which should be excluded in the ALIASES. For example —
User_Alias EXCEPT_ROOT = ALL, !root
sysadmin ALL = (EXCEPT_ROOT) /usr/sbin/apache2
This User_Alias can be used to make sure that a USER can execute the specified command as “all users except ROOT”.
This kind of exclusion can be done in all the ALIASES, not only User_Alias. In any ALIAS, exclusion syntax remains the same.
Handling Sudoers File with Care
By now you must have understood what a Sudoers file can do and how important it is to handle the file with Care. Linux already implements a mechanism to make sure that the Sudoers file is handled properly.
It is always recommended NOT TO EDIT /etc/sudoers file DIRECTLY. There’s a tool called as “visudo”. This is used to safely make changes to a sudoers file. When you edit sudoers file using visudo, visudo has an inbuilt functionality to check the syntax before saving the file, if you make a mistake it will immediately point the line out where syntax is not proper. This functionality of visudo will prevent from causing any accidental damage to the file and system.
Conclusion:
Sudoers file always plays a major role in User Control Management. While there are many ways to manage and control what a user can and cannot do on the system, Sudoers method will always be efficient and robust enough to manage and control any no. of users. One more method similar to this which is worth mentioning is SUID and SGID. We will talk about SUID and SGID in another article.
Thank you for reading. You can connect with me on Linkedin . Happy to answer your queries.
