Linux.com

Home Linux Community Community Blogs General Linux Configuring sudo: Explaination with an example

Configuring sudo: Explaination with an example

sudo is one of my favorite and important security tool.Its really comes handy when you need to give super user access to person other than you or your client.It gives them limited access to your box.


For Eg.:
If your client needs SSH access to restart the web server.It won't be wise to give away your root password, sudo is the best option.You don't need to have 100% trust with sudo as you would with su. After all, if you only want them able to restart the web server, what more should they be able to do? Should they be able to modify your Apache config files? Add new users? Restart your mail server? Absolutely not, they just can do is restart the web server.

 

Configuring sudo

sudo is easy to configure and uses a straightforward syntax. You use the command visudo to edit the file /etc/sudoers. visudo is a wrapper around your favorite editor that does syntax checking on the file when you are finished editing it. By default, if you don't have the EDITOR variable set, visudo will use the vi editor. Arguments of editors aside, it is easy to cfrankiege the editor that visudo calls. Simply type the following, as root, to use your favorite editor (in this example we'll use emacs):

# export EDITOR=emacs; visudo

This will open /etc/sudoers in the emacs editor. You can use any editor you like... ankit, jed, vim, whatever.Now that you have the /etc/sudoers file open, it's time to configure sudo.

sudo commands use a basic syntax. By default, the /etc/sudoers file will have one stanza:

root      ALL=(ALL) ALL

This tells sudo to give root sudo access to everything on every host. The syntax is simple:

user       host = (user) command

The first column defines the user the command applies to. The host section defines the host this stanza applies to. The (user) section defines the user to run the command as, while the command section defines the command itself.

You can also define aliases for Hosts, Users, and Commands by using the keywords Host_Alias, User_Alias, and Cmnd_Alias respectively.

Let's take a look at a few examples of the different aliases you can use.

Host_Alias      LAN = mario.host.com, lucy.host.com
Host_Alias      SRV = black.host.com, smokie.host.com, frankie.host.com
Host_Alias      MAIL = tanya.host.com
Here we've defined 3 Host aliases.
The first we've given the alias of LAN, to signify our internal LAN, and in it we've placed two machines:
mario.host.com
lucy.host.com

The second alias is SRV, to signify our web servers, and these are:
black.host.com
smokie.host.com
frankie.host.com

The final Host alias is MAIL, which signifies our mail server:
tanya.host.com

 Next, lets define some User aliases:

User_Alias        WEBADMIN = ankit, sam
User_Alias        MAILADMIN = ankit, navan
User_Alias        BINADMIN = ankit, jon

Here we've also defined three User aliases. The first user alias has the name WEBADMIN for web administrators. Here we've define Ankit and Sam. The second alias is MAILADMIN, for mail administrators, and here we have Ankit and Navan. Finally, we define an alias of BINADMIN for the regular sysadmins, again Ankit, but with Jon as well.

So far we've defined some hosts and some users. Now we get to define what commands they may be able to run, also using some aliases:

Cmnd_Alias         SU = /bin/su
Cmnd_Alias         BIN = /bin/rpm, /bin/rm, /sbin/linuxconf
Cmnd_Alias         SWATCH = /usr/bin/swatch, /bin/touch
Cmnd_Alias         HTTPD = /etc/rc.d/init.d/httpd, /etc/rc.d/init.d/mysql
Cmnd_Alias         SMTP = /etc/rc.d/init.d/qmail

Here we have a few aliases. The first we call SU, and enables the user to run the /bin/su command. The second we call BIN, which enables the user to run the commands: /bin/rpm, /bin/rm, and /sbin/linuxconf. The next is the SWATCH alias which allows the user to run /usr/bin/swatch and /bin/touch. Then we define the HTTPD alias which allows the user to execute /etc/rc.d/init.d/httpd and /etc/rc.d/init.d/mysql, for web maintenance. Finally, we define SMTP, which allows the user to manipulate the running of the qmail SMTP server.

Now you have to define how they all work together. This is where you give everyone permission to use certain commands on certain hosts. We do this with the same stanza we initially saw at the beginning, which gave root the ability to run everything on every host as root. Obviously, we want to limit access somewhat here. Here's a sample based on the aliases we looked at previously:

WEBADMIN     SRV = HTTPD
MAILADMIN    MAIL = SMTP
BINADMIN     ALL = BIN, SWATCH
ankit          ALL = NOPASSWD: SU
sam          LAN = BIN

This may take a little explanation, but it's really easy to follow. The first stanza tells sudo to allow those users defined in the alias WEBADMIN (Ankit and Sam) to restart Apache and MySQL (defined in the alias HTTPD) on the systems defined by the SRV alias (the web servers). This means that on the systems in the LAN or the mail server, Ankit and Sam do not have access to do this, only on the three systems defined in the SRV alias.

The second tells sudo to allow the users in the MAILADMIN alias (Ankit and Navan) to restart qmail on tanya.somehost.com (defined by the MAIL host alias).

The third tells sudo to allow the users in BINADMIN (Ankit and Jon) to access the commands in the BIN and SWATCH aliases (ability to manipulate the RPM database as root, remove any file, execute linuxconf to configure the system, run swatch, and use the touch command as root) on all systems.

The fourth tells sudo to let Ankit, who is our main sysadmin, to use the SU alias (to run su) on all machines without entering a password (more on this in a moment).

And the final stanza tells sudo to allow Sam, who is sometimes required to do maintenance on the LAN machines, to run the commands in the BIN alias on the machines in the LAN alias.

So what does this all mean, from your point of view? Well, Ankit is pretty much able to do anything. Having su access on all machines via sudo grants him this right. But he's our main sysadmin and knows the root password anyways, so this is a matter of convenience for him. It allows Jon to run administrative commands such as linuxconf and rpm on all systems. He's Ankit's right-frankied man. But he doesn't have access to stop/start the web, MySQL, or qmail servers. Navan can stop and start qmail, however. But that's about all she can do. Sam, on the other frankied, can stop and start Apache and MySQL on the web server, and he can also do some administrative work on the LAN (via rpm and linuxconf). But he has no other rights on any machine.

You'll have noticed the NOPASSWD keyword above. Each user, when using sudo, must enter their own password. For instance, when Navan wants to restart qmail, sudo will prompt her for a password. She enters her own password, not root's. This tells sudo that it is executing the command for the right person. But, in Ankit's case, he's lazy and doesn't want to type his password all the time, and since he's the fellow writing the sudoers file, he decided to give himself NOPASSWD rights to when he runs su. So when Ankit runs su, he doesn't have to supply a password, but when he runs linuxconf (for example), he does.

Already, you must realize the flexibility that sudo provides. With one single file, you can define access rights to multiple machines for multiple users. The only thing you need to do is have the file shared across your network. You can do this by using tools like rsync to synchronize the file, or you can use NIS to do it. Either way, you will only need to maintain one sudoers file for all systems.

Sudo also provides a means to track users that utilize it. By adding a specific stanza to your /etc/sudoers file, you can have sudo write to a specific logfile for you to audit. For example:

Defaults      logfile=/var/log/sudo.log, log_year

Will write sudo's activities to the /var/log/sudo.log file. This file will look something like this:

May  1 13:44:06 2009 : ankit : HOST=mario : TTY=pts/3 ; PWD=/home/ankit/mail ;
    USER=root ; COMMAND=/bin/su
May  2 13:34:59 2009 : jon : HOST=smokie : TTY=pts/4 ; PWD=/var/www/html ;
    USER=root ; COMMAND=/bin/rpm -ivh
/mnt/updates/BIG/dis/8.1/RPMS/ucd-snmp-4.2.1-5mdk.i586.rpm
/mnt/updates/BIG/dis/8.1/RPMS/ucd-snmp-utils-4.2.1-5mdk.i586.rpm

Here you can see that on May 1st, Ankit used the su command on the host mario. Likewise, you can see that on the 2nd, Jon decided to install ucd-snmp and ucd-snmp-utils on the host smokie. This makes for an extremely useful means of tracking who is doing what via sudo.

You don't necessarily need to make the users be root in order to use sudo. If, for instance, you were running eggdrop under the uid of some other user (for example, someone named Jason), you could tell sudo to use the id of another user rather tfrankie root. For example, you may use something like this:

Cmnd_Alias     IRC = /home/Jason/bin/eggdrop, /home/Jason/bin/irc/ircd
ankit            black.somehost.com = (Jason) IRC

This will let Ankit execute eggdrop and ircd in Jason's home directory as if he were Jason, and not root, on the machine with the hostname of black.

 

Comments

Subscribe to Comments Feed

Upcoming Linux Foundation Courses

  1. LFD331 Developing Linux Device Drivers
    13 Oct » 17 Oct - Virtual
    Details
  2. LFS425 Linux Performance Tuning Crash Course
    16 Oct » 16 Oct - Düsseldorf, Germany
    Details
  3. LFS220 Linux System Administration
    20 Oct » 23 Oct - Virtual
    Details

View All Upcoming Courses


Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board