<<

Sudo And Sudoers

Using sudo

If a server needs to be administered by a number of people it is normally not a good idea for them to all use the "root" account. This is because it becomes difficult to determine exactly who did what, when and where if everyone logs in with the same credentials. The sudo utility was designed to overcome this difficulty.

The sudo utility allows users defined in the /etc/sudoers configuration file to have temporary access to run commands they would not normally be able to due to file permission restrictions. The commands can be run as user "root" or as any other user defined in the /etc/sudoers configuration file.

The privileged command you want to run must first begin with the word "sudo" followed by the command's regular syntax. When running the command with the sudo prefix, you will be prompted for your regular password before it is executed. You may run other privileged commands using sudo within a five minute period without being re-prompted for a password. All commands run as sudo are logged in the log file /var/log/messages.

Sample Of A User Using sudo

In this example, user "bob" attempts to view the contents of the /etc/sudoers file, which is an action that normally requires privileged access. Without sudo, the command fails.

[bob@bigboy bob]$ more /etc/sudoers
/etc/sudoers: Permission denied

[bob@bigboy bob]$

Bob tries again using sudo and his regular user password and is successful

[bob@bigboy bob]$ sudo more /etc/sudoers
Password:

...

...

[bob@bigboy bob]$

The details of configuring and installing sudo will be covered in later sections.

The visudo Command

"visudo" is a text editor that mimics the "vi" editor that is used to edit the /etc/sudoers configuration file. It is not recommended that you use any other editor to modify your sudo parameters as the sudoers file isn't located in the same directory on all versions of Linux. "visudo" uses the same commands as the "vi" text editor. "visudo" must run as user "root" and should have no arguments as seen below.

[root@aqua tmp]# visudo

The /etc/sudoers File

The /etc/sudoers file contains all the configuration and permission parameters needed for sudo to work. There are a number of guidelines that need to be followed when editing it with visudo.

General /etc/sudoers Guidelines

The /etc/sudoers file has the general format of:
usernames/group servername = (usernames command can be run as) command
root,bob ALL=(ALL) ALL

There are some general guidelines when editing this file:
*Groups are the same as user groups and are differentiated from regular users by a % at the beginning. The Linux user group "users" would be represented by %users.
*You can have multiple usernames per line separated by commas
*Multiple commands can be separated by commas too. Spaces are considered part of the command.
*The keyword "ALL" can mean all usernames, groups, commands and servers.
*If you run out of space on a line, you can end it with a "\" and continue on the next line.
*Sudo assumes that the sudoers file will be used network wide, and therefore offers the option to specify the names of servers which will be using it in the "servername" position (see above). In most cases, the file is used by only one server and the keyword "ALL" will suffice for the server name.
*The NOPASSWD keyword provides access without you being prompted for your password

Simple /etc/sudoers Examples

Here are some simple examples of how to do many commonly required tasks using the sudo utility.

Granting All Access To Specific Users
You can grant users "bob" and "bunny" full access to all privileged commands, with this sudoers entry.

bob, bunny ALL=(ALL) ALL

This is generally not a good idea as this allows "bob" and "bunny" to use the su command to grant themselves permanent "root" privileges thereby bypassing the command logging features of sudo. The example on using "aliases" in the sudoers file shows how to eliminate this problem.

Granting Access To Specific Users To Specific Files
This entry allows user "peter" and all the members of the group "operator" to gain access to all the program files in the /sbin and /usr/sbin directories, plus the privilege of running the command /usr/local/apps/check.pl. Notice how the trailing slash "/" is required to specify a directory location.

peter, %operator ALL= /sbin/, /usr/sbin, /usr/local/apps/check.pl

Notice also that the lack of any username entries within brackets () after the "=" sign prevents the users from running the commands as another user. This will be explained further in the next example.

Granting Access To Specific Files As Another User
The "sudo -u" allows you to execute a command as if you were another user, but first you have to be granted this privilege in the sudoers file.

This feature can be convenient for programmers who sometimes need to kill processes related to projects they are working on. For example, programmer "peter" is on the team developing a financial package that runs a program called "monthend" as user "accounts". From time to time the application fails, requiring "peter" to stop it with the /bin/kill, /usr/bin/kill or /usr/bin/pkill commands but only as user "accounts". The sudoers entry would look like this:

peter ALL=(accounts) /bin/kill, /usr/bin/kill /usr/bin/pkill

User "peter" would now be allowed to stop the "monthend" process with this command:

[peter@bigboy peter]# sudo -u accounts pkill monthend

Granting Access Without Needing Passwords
This example allows all users in the group "operator" to execute all the commands in the /sbin directory without the need for entering a password. This has the added advantage of being more convenient to the user.

%operator ALL= NOPASSWD: /sbin/

Using Aliases In The sudoers File

Sometimes you'll need to assign random groupings of users from various departments very similar sets of privileges. The sudoers file allows users to be grouped according to function with the group then being assigned a nickname or "alias" which is used throughout the rest of the file. Groupings of commands can also be assigned aliases too.

In the example below, users "peter", "bob" and "bunny" and all the users in the "operator" group are made part of the user alias "ADMINS". All the command shell programs are then assigned to the command alias "SHELLS". Users ADMINS are then denied the option of running any SHELLS commands and su.

Cmnd_Alias SHELLS = /usr/bin/sh, /usr/bin/csh,

/usr/bin/ksh, /usr/local/bin/tcsh,

/usr/bin/rsh, /usr/local/bin/zsh


User_Alias ADMINS = peter, bob, bunny, %operator

ADMINS ALL = !/usr/bin/su, !SHELLS

This attempts to ensure that users don't permanently "su" to become root, or enter command shells that bypass sudo's command logging. It doesn't prevent them from copying the files to other locations to be run. The advantage of this is that it helps to create an audit trail, but the restrictions can only be enforced as part of the company's overall security policy.

Other Examples

You can view a comprehensive list of /etc/sudoers file options by issuing the command "man sudoers".

Using syslog To Track All sudo Commands

All sudo commands are logged in the log file /var/log/messages which can be very helpful in determining how user error may have contributed to a problem. All the sudo log entries have the word "sudo" in them, so you can easily get a thread of commands used by using the grep command to selectively filter the output accordingly.

Here is sample output from a user "bob" failing to enter their correct sudo password when issuing a command, immediately followed by the successful execution of the command "/bin/more sudoers".

[root@bigboy tmp]# grep sudo /var/log/messages
Nov 18 22:50:30 bigboy sudo(pam_unix)[26812]: authentication failure; logname=bob uid=0 euid=0 tty=pts/0 ruser= rhost= user=bob
Nov 18 22:51:25 bigboy sudo: bob : TTY=pts/0 ; PWD=/etc ; USER=root ; COMMAND=/bin/more sudoers
[root@bigboy tmp]#