‘sudo’ and its functions

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

‘sudo’ and its functions

After disabling root login you will not able to login to the server server as root. One way to access the server with full privilege is via wheel users. If a server needs to be administered by a number of people it is normally not a good idea for them all to use the wheel user and 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.

Adding sudo users

To add sudo users to the server execute either of the following command.

root@myserver ~> visudo

root@myserver ~> vi /etc/sudoers { normally this is a read-only file and a you need to edit the permission if you wish to change the file in this way.}

The general format in the file /etc/sudoers is

usernames/group servername = (usernames command can be run as) command

We can use sudo in various forms to grant privileges. some examples are given below.

a)  Granting All Access to Specific Users

You can grant user sakafi full access to all privileged commands, with this sudoers entry.

sakafi  ALL=(ALL) ALL

This is generally not a good idea because this allows sakafi to use the su command to grant themselves permanent root privileges thereby bypassing the command logging features of sudo.

b) Granting Access To Specific Users To Specific Files

This entry allows user sakafi and all the members of the group syadmins 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.

sakafi, %sysadmins ALL= /sbin/, /usr/sbin/, /usr/local/apps/check.pl

Notice also that the lack of any username entries within parentheses () after the = sign prevents the users from running the commands automatically masquerading as another user.

c) Granting Access to Specific Files as Another User

The sudo -u entry allows 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, User A is runs a program as user accounts. From time to time the application fails, requiring “sakafi” 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:

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

Means User sakafi is allowed to access the files as accounts

d) Granting Access Without Needing Passwords

This example allows all users in the group sysadmins 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:

%sysadmins ALL= NOPASSWD: /sbin/

e) 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 and 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 this example, users userA, userB and userC and all the users in the sysadmins group are made part of the user alias . 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 = userA, userB, userC, %sysadmins
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 be enforced only as part of the company’s overall security policy.

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 sakafi failing to enter their correct sudo password when issuing a command.

root@myserver ~> grep sudo /var/log/messages
Mar  7 11:25:12 myserver sudo(pam_unix)[10671]: authentication failure; logname=sakafi uid=0 euid=0 tty=pts/2 ruser= rhost=  user=sakafi


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s