dcsimg

Sudo Voodoo

Using the root account for day-to-day work is a bad idea. It's better to use sudo to act like root when you need to do a little system administration. Ken Hess shows you how.

A Linux system has two kinds of users: ordinary users and the root user. Each ordinary user has a robust set of permissions to manage his or her own files (and files that belong to a group that he or she is a member of), but an ordinary user cannot affect system configuration, start or stop essential services such as the SSH daemon, and cannot reserve a so-called privileged port, or any networking port numbered less than 1,024. The root user, though, is free to access and modify any file, perform any task, and affect the system at will.

Of course, as Spider-Man says, ‘With great power comes great responsibility.’ root must be cautious, because a small typo can lead to disaster. For example, there’s a big difference between the command rm -rf /a and rm -rf /. Given the potential for such accidental cataclysms, it’s considered a best practice to never log in as root, lest you forget or misdirect the (remaining in the Marvel Comics universe) Thor-like power you wield.

Indeed, many Linux distributions preclude root logins, preferring instead to grant the initial user the right to act like root when necessary. This special privilege, which can be extended to other users on the system, is managed via the sudo (pronounced ‘soodoo’) utility. sudo controls who can act like root, and can further control what a user can do as root.

When a task requires root powers, and assuming the user has the right to perform the task at hand as root, the user simply prefaces the command with sudo. For example, say the /tmp directory is filled with oodles of scratch files created by a myriad of users. While each user can only remove his or her own scratch files, a user with the right to run rm as root (as dictated by sudo) can clean the entire directory with one command:

$ whoami
khess
$ sudo rm -rf /tmp/*

The user khess has limited rights. However, prefacing the command with sudo invokes the command as if the user was root. Yes, you can still make a typo and remove all of /tmp, but sudo minimizes the use of root privileges and hence the risk of mistakes.

So su Me

sudo is something of a specialized version of another ‘alter ago’ application named su, short for ‘substitute user.’ su allows one user to temporarily act like another. Specifically, su runs a shell with substitute user and group IDs. Any user may issue /bin/su and switch to any other user account, including root, if the substituted user’s password is known.

$ whoami
khess
$ su - bob
Password:
$ whoami
bob
$ exit
$ whoami
khess

The - option starts a login shell as the user bob. Once you type Bob’s password at the prompt, you are bob. Every file you create or process you start is owned by Bob. If you exit the login shell spawned by su, your original user and group IDs are restored, as shown above.

su can also be used to become root just as it’s used to become bob, or any other user.

$ su -
Password:

Assuming you know the root password, su - (the username is omitted) changes your user and group ID to root.

However, disseminating root’s password isn’t recommended because it poses a serious security risk. If the password fell into the hands of a malcontent, the system (or many systems) could be compromised.

To enhance the security of su, change the permissions of /bin/su to allow only root and group admin access:

# chgrp admin /bin/su
# chmod o-rwx /bin/su
# ls -l /bin/su
r-sr-x--- root admin '

Here, read and execute rights have been rescinded for ‘other’, and the group owner has been changed to limit access to the members of the admin group. This is the recommended setup for a multiuser system.

Who Do You sudo?

Even if su is restricted, it’s use still requires the root password. A leaked password is one risk, but changing the root password frequently may also lead to problems, as passwords, especially well-constructed cyphers, are difficult to remember. sudo was invented to solve these two issues and more. sudo catalogs who can become root and what the user can run as root. The catalog is maintained in /etc/sudoers.

To determine if you have sudo privileges, run the command sudo -l.

$ sudo -l
Password:

Here, you must enter your password to authenticate yourself, preventing a miscreant from abusing your privileges. If you do not have sudo access, you’ll receive a message similar to:

Sorry, user fred may not run sudo on this host

Otherwise, sudo presents the list of commands that you have rights to execute:

$ whoami
fred
$ sudo -l
Password:
User fred may run the following commands on this host:
    (root) /usr/local/bin/apachectl

As you can see, fred can control the Apache HTTP Server daemon via apachectl as root.

After you invoke sudo and provide your password, sudo provides a ‘ticket’ good for five minutes of access. During these five minutes, you need not provide your password again to run additional commands via sudo.

In fact, each command you execute within five minutes extends the five-minute window. However, if you fail to issue any command using sudo within five minutes, the ticket expires and you must re-authenticate to re-use sudo. A timeout precludes others from usurping your privileges while you’re out to lunch or otherwise away from the computer.

Here’s an example of a series of sudo commands to copy and edit a file and restart Apache:

$ sudo cp -p index.html index.html.20070511
Password:
$ sudo vi index.html
$ sudo apachectl restart

You must prepend each command with sudo. If you don’t prepend the command with sudo, the system assumes you are issuing the command as yourself.

How Do You sudo?

As shown above, sudo need not be the key to Pandora’s Box. A user can be restricted to run a collection of commands. fred, for instance, can stop, start, and restart Apache via apachectl, but cannot run rm or vi.

To edit the sudo catalog, /etc/sudoers you must use a special editor named visudo. The catalog has a somewhat complex and specific format. Listing One is an example sudoers file.

Listing One: A sample /etc/sudoers file

# User privilege specification
root    ALL=(ALL) ALL
%admin  ALL=(ALL) ALL
strike  ALL=(ALL) NOPASSWD:ALL

# Uncomment to allow people in group wheel to run all commands
%wheel        ALL=(ALL)       ALL

  • The first field is either a user name, such as strike, or a group name, such as %admin or wheel.

  • The second field specifies a list of hosts. (Since the same sudoers file may be copied to all machines on the network for consistency, you may allow different privileges on different hosts.) The abbreviation ALL matches any hostname.

  • The third field (the one in parentheses following the =) enumerates usernames or IDs. A command can run as any of the listed users. This is valuable when you need to stop, start, restart, kill a process that isn’t owned by root. (Of course, you can kill any process as root, but you may not want to start any process as root, inadvertently giving a simple service root privileges.) Again, ALL matches any user.

  • The fourth field lists the commands that can be run.

Or, put more simply, the fields are:

Username    Hosts=(Usernames or UIDs)) Commands

Separate multiple entries for any of the latter fields with commas. (You can refer to the sudoers man page for details.)

Hence, this user privilege specification:

root    ALL=(ALL) ALL

allows the root user to run all commands on all hosts as any user. Similarly, if you’re fred and use a desktop Linux system, /etc/sudoers probably contains an entry like this:

fred    ALL=(ALL) ALL

This is reflected by sudo -l:

$ sudo -l
Password:
User fred may run the following commands on this host:
    (ALL) ALL

To run a command as a user other than root (assuming sudoers permits it), use the -u option:

$ sudo -u nobody /etc/init.d/some_service restart

This restarts some service as the user nobody. To issue more than one command as another user, the switch must be used each time you invoke sudo. If you omit -u, root is assumed.

Sudo’s and Sudon’ts

Here’s a list of things to do and to avoid when you setup and use sudo. Do:

  • Specify the full path to all commands for aliases and single commands.

  • Use aliases for hosts, groups, and commands. (See the man page to create aliases.)

  • Follow the principle of ‘least privilege’: Only grants those rights that are needed and nothing more, and be explicit.

  • Check the log files /var/log/auth.log or /var/log/secure often for sudo usage and violations.

Don’t:

  • Don’t try to exclude commands from ALL. (Again, use aliases.)

  • Never grant ALL=(ALL) ALL to anyone.

  • Do not specify the NOPASSWD modifier for regular users. NOPASSWD allows a user to use sudo without password authentication.

Sudo You Think You’re Foolin’?

A great many problems can be solved by using sudo. Best of all, you don’t have to give the root password to anyone other than administrators or the system owner. Clever use of sudo can track privileged use on a system.

However, sudo can also create exploits if you allow users too much access. For example, if you permit a user to have access to ALL, the user can become root permanently (until their next login, anyway) using the command sudo su - or sudo /bin/bash. Implementing sudo policies should be a well- thought out undertaking. sudo can either bring much comfort to nervous administrators or much heartache to cavalier ones.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62