This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: System Administration

sudo, or not sudo: that is the question

By Federico Kereki on February 07, 2008 (4:00:00 PM)

Share    Print    Comments   

If you've dabbled even a little bit with security matters, you know that giving root rights or the root password to a common user is a bad idea. But what do you do if a user has a valid need to do something that absolutely requires root rights? The answer is simple: use sudo to grant the user the needed permissions without letting him have the root password, and limit access to a minimum.

With sudo (which stands for "superuser do"), you can delegate a limited set of administrative responsibilities to other users, who are strictly limited to the commands you allow them. sudo creates a thorough audit trail, so everything users do gets logged; if users somehow manage to do something they shouldn't have, you'll be able to detect it and apply the needed fixes. You can even configure sudo centrally, so its permissions apply to several hosts.

After you've installed and configured your host, users can use sudo aForbiddenCommand to run something they previously couldn't run. sudo will ask for their password -- not the root one -- to provide a basic defense against passersby using a console that was left unattended. The users won't be able to do anything they want; they'll only be able to do whatever you allow them in the sudo configuration, which minimizes the risk to your system.

Installation and configuration

sudo sports a long history; its first version ran on BSD in around 1980, and since then, updates have come frequently. If it's not already on your system, you can generally install it from the repositories of your favorite distribution.

sudo is free software, available under an Internet Systems Consortium (ISC)-style license. Both a stable version (currently 1.6.9p12, released on January 20) and a development branch (at version 1.7b1) are available. Because sudo has to do with system security, I encourage you to use the former. If you want to install from source, you can find the source on the GratiSoft Web site. Installation is simple, along the lines of the classical configure, make, make install. However, you might want to check some of the configuration options; for example, you can have sudo insult the user should he enter a wrong password!

Configure sudo by editing /etc/sudoers, which includes, as the name implies, which users can sudo at will. This file has "400" permissions, meaning that only root can read it and nobody can write it. To edit this file, you must use visudo, a program that takes care of the permissions, sets up some locks so two different users can't edit the file at the same time, and even checks to make sure you didn't make a mistake before saving it. visudo runs whichever editor you specify in the EDITOR environment variable -- usually vi.

The format of the sudoers file is simple: it starts with four optional sections, and it ends with the specific rights assignments. It can include empty lines, or comment lines that start with the # sign. The optional sections are:

  • User Alias: Specifies an alias for a single user (not very useful) or a set of users. A user can appear in several aliases.
  • "Run as" Alias: Specifies which other user(s) the sudo user will be able to work as. By default, sudo implies root, but you might want to run as another user.
  • Host Alias: Specifies the hosts that the rights apply to. You won't be using this unless you're doing sysadmin jobs for a group of several Linux boxes. You would have to rsync the file to the other hosts, or use something like Network Information Service (NIS) to provide access to the file.
  • Command Alias: Specifies a synonym for a specific command. For instance, it's easier to type APT than a fully qualified absolute path such as /usr/sbin/apt-get.

You don't need to use aliases, but they do make future editing easier. For example, if you have to assign donald_duck the same rights that mickey_mouse has, just add the former to the latter's group, and you won't have to spend lots of time duplicating lines everywhere. A special alias called ALL exists, and you can use it anywhere; it can mean ALL users, ALL hosts, and so on.

After these sections, you must have a section for specific rights, which looks like "who where = (whoelse) what," meaning who (a user, a group, or a user alias) on the host where can run a command what as a user whoelse. (If this is too cryptic, look at the following example.) You can also include several specific options, such as NOPASSWD to allow a user to sudo without entering his password; check the manual for the other options.

This sample doesn't show every configuration possible (for that, you should do man sudoers), but here's what a sample file with some of these options might look like:

# # Sample /etc/sudoers file, with apologies to the Disney company! # # User aliases # The first line creates an alias for three specific users. # The second one includes everybody in the "ducks" user group, but excludes "donald" # The third one creates an alias for just one user; it can be useful in the future! # User_Alias NEPHEWS = huey, dewey, louie User_Alias ALL_DUCKS_BUT_DONALD = %ducks, !donald User_Alias MICKEY = mickey_mouse # Command aliases Cmnd_Alias HALT_OR_REBOOT = /sbin/halt Cmnd_Alias KILL = /usr/bin/killall Cmnd_Alias SHUTDOWN = /sbin/shutdown Cmnd_Alias SU = /bin/su # The rights: who gets to run what # A standard rule: root, and users in group "wheel", have full rights root ALL = (ALL) ALL %wheel ALL = (ALL) ALL # Suppose mickey is an sysadmin; let him run anything without a password MICKEY ALL = NOPASSWD: ALL # NEPHEWS can stop the box if they want NEPHEWS HALT_OR_REBOOT, SHUTDOWN

You can also add some extra configuration lines at the end of the configuration file. You can specify, for example:

  • Whether emails should be sent for wrong passwords or unallowed attempts to use sudo
  • How many login attempts to allow before exiting
  • Whether the user should get a short lecture about the risks involved in using sudo
  • A log file specific to sudo, where all commands will be logged

When you quit the editor, visudo checks for errors and lets you know whether something is wrong; you can go back to editing or cancel all your changes. The third option, saving the file with an error, can make it impossible for anybody to use the sudo command until you fix the mistake, so that's not a good idea.

Be careful

When allowing rights, be careful, or you might end up allowing more than you expected. Of course, if you allow a user to do su, then he will get full root rights; did you really want that? This is rather obvious, but there are more subtle traps. For example, if a user is allowed to sudo less, he could then use the ! command and start running any other command as root. (If you don't know about risks like this, read the Unix man pages that talk about it.) Just in case, before allowing access to a command, check online security sites such as the SANS Institute and search for exploits or vulnerabilities; better safe than sorry.

Another easy mistake is using relative paths for commands; a knowledgeable user could easily hack his way to full rights. Suppose you defined an alias FOO as equivalent to merely bin/foo; a user might be able to create a bin directory somewhere, copy any command he wishes to it (but, most importantly, naming it "foo"), and then run it as root and do anything he wants.

Unfortunately, there's no guarantee that a user won't ever be able to find a way to manage a privilege escalation and work as root, but there's no other easy viable way to allow someone to do something that requires higher levels of access.

While there are some possible risks (mostly having to do with carelessly given rights), using sudo provides you a way to allow specific users to go beyond their normal rights to do specific tasks.

Federico Kereki is an Uruguayan systems engineer with more than 20 years' experience developing systems, doing consulting work, and teaching at universities.

Share    Print    Comments   

Comments

on sudo, or not sudo: that is the question

Note: Comments are owned by the poster. We are not responsible for their content.

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 58.110.209.60] on February 07, 2008 04:46 PM
Quote: 'Of course, if you allow a user to do su, then he will get full root rights'

- not so.

'su' means 'switch user' - the user can only become root with a root password, unless /etc/sudoers specifies that user or group as having ALL rights to everything.

'su' can be used, for example, to change from being user huey to user louie, but huey would need to know louie's password. To become root, huey would need the root password if using 'su'

#

Re: sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 58.110.209.60] on February 07, 2008 04:50 PM
Ah, I correct myself - the writer is presumably talking about 'sudo su' - I probably misunderstood.

#

sudo as RBAC

Posted by: Anonymous [ip: 169.233.27.26] on February 07, 2008 07:00 PM
I noticed that sudo can be used to do some of the things (I can't say all of the things for sure) that Solaris calls RBAC (fine grained capabilities, which I believe Linux (yes, the kernel, not GNU/Linux, so go away RMS) implemented and are accessible through getpcap and setpcap). Very interesting indeed.

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 75.38.21.142] on February 07, 2008 09:32 PM
You can eliminate the sudoers file and even visudo if you have an ldap server and load the sudo schema. Nice centralization of sudo rights in that scenario.

#

Graphical tasks?

Posted by: Anonymous [ip: 208.235.233.194] on February 07, 2008 09:39 PM
What if the task the user needs root access to perform is gui-related? Ex: modifying the date/time by right-clicking on the system tray clock in KDE? This brings up a box into which the root password must be typed. Can sudo help in this case? If not, what can?

Thanks,

Evan
ebradley03 AT gmail DOT com

#

Re: Graphical tasks?

Posted by: Anonymous [ip: 200.87.59.3] on February 08, 2008 11:22 AM
You may need to use gksudo, but now you need to enter the command and not just double click.

gksudo [command]

but if you systems grants the permission for some minutes, during those minutes you may be able to double click.
Anyway, almost (I say almost because I an not Linux expert) any graphical task can be performed from the command line

#

Re(1): Graphical tasks?

Posted by: Anonymous [ip: 208.235.233.194] on February 08, 2008 02:45 PM
Thanks for the tip re: gksudo (and the KDE counterpart, kdesu), but when the dialog box appears, it still demands the true root password and will not accept that of the user who invoked the gksudo, even if they are in the sudoers file, and are able to use sudo from the command line.

#

Re(2): Graphical tasks?

Posted by: Anonymous [ip: 208.235.233.194] on February 08, 2008 02:58 PM
That is my reply above, sorry for not leaving my name. I figured out a way to allow users to run a graphical command without having to enter the root password. Perhaps if I had RTFA a bit closer, I wouldn't have needed to comment at all. ;) By using the NOPASSWD option in the sudoers file, the graphical command (sudo kcmshell kde-clock.desktop, in this case) is run without the password dialog box appearing, as one would expect. One can at that point decide whether or not to include the ALL option for the user in question, (yes I know its a security risk) or to compose a list of commands the user can access without a password. --Evan

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 203.2.120.51] on February 08, 2008 02:02 AM
sudo can do some things more easily than RBAC can, and RBAC can do other things more easily than sudo can. By judicious composition of your sudoers file, you can lock down the full command line with predermined arguments, but RBAC gives you some access to kernel security niceness. From prior experience sudo gives you a little more rope, but wont stop you hanging yourself, while RBAC is miserly with the cord but accidental garotting is more difficult

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 200.87.59.3] on February 08, 2008 11:19 AM
I really like sudo, I learn about it, when using Ubuntu, now I use Debian, and always install sudo, first and edit the sudoers file,

I also wrote about it, days ago:

http://www.go2linux.org/sudoers-how-to

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 88.70.26.148] on February 08, 2008 12:53 PM
sudo = substitute user do

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 74.235.200.127] on February 09, 2008 05:58 PM
eVeRyOnE sHoUlD jUsT rUn As r00t cAuSe LiNuX iS sEcUrE

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 24.34.63.246] on February 09, 2008 06:21 PM
Root is god. Not the regular user. You've got it all wrong here.. there is no making acceptions for actions that require access! ROOT IS GOD. I'AM THE OPERATOR.

#

sudo, or not sudo: that is the question

Posted by: Anonymous [ip: 83.105.112.179] on February 10, 2008 12:18 PM
The way most sudo setups are run can actually make things less secure. A user who can do 'sudo su', or 'sudo bash' is effectively root equivalent immediately, as is anyone who has sudo on chmod and chown, in addition to less and many other things. This means that compromise of root rights simply needs an attacker to crack a user password - privilege elevation via an exploit becomes unnecessary. Having sudo set up can be useful for logging, but it's difficult to delegate enough rights via sudo to allow someone to perform any degree of sysadmin without giving them root. It is not a panacea for security, and its implementation by default in distros where 'sudo su -' is the way to get root is not adding to security, it's actually siginificantly less secure than having a string root password.

#

root privileges plus logging of keystrokes

Posted by: Anonymous [ip: 10.0.1.166] on February 11, 2008 04:15 PM
we heavily use rootsh (http://sourceforge.net/projects/rootsh). this tool when called as "sudo rootsh" gives a user a root shell, but logs every keystroke into a logfile and/or syslog. sometimes users scream so loud for more privileges (developers need to install their software for example), that we get the direct order from the management to grant them. with rootsh we can protocol their actions and can prove them guilty if they broke something and deny it.

#

What sudo might be good for

Posted by: Anonymous [ip: 89.174.122.93] on February 11, 2008 08:09 PM
Sudo is good, if there are some services, that need access to few root privileges. For example, you can configure nagios to restart some service, if it breaks. Generally it's better than allow nagios run particular commands as superuser, then to have entire nagios started as root.

One of main reasons, why Unixes are so secure is because services get as little privileges as possible. Sudo is really helpful with that.

#

Why not use TOMOYO Linux?

Posted by: Anonymous [ip: 122.29.101.179] on February 14, 2008 11:20 AM
TOMOYO Linux is designed to be able to restrict behaviors of users in login session, especially system administrative tasks after SSH login.
It can restrict programs that the user can execute and files that the user can read/write for per-a-pathname basis (whereas SELinux restricts then for per-a-label basis).

No worry for "sudo less", for TOMOYO Linux can permit execution of "/usr/bin/less", but can forbid execution of "/bin/sh" from "/usr/bin/less".
No worry for command injection bugs, for TOMOYO Linux can perform access control with "what programs can the user execute from that process" and "what files can the process open" (e.g. TOMOYO Linux can permit /usr/bin/md5sum but forbid /bin/cat , whereas SELinux can't do so by default because /bin/cat and /usr/bin/md5sum have the same label).

TOMOYO Linux is friendly with /usr/bin/sudo since TOMOYO Linux is pathname based like /usr/bin/sudo .

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya