Summary

Being Someone Else for a While: su, sudo

Because Unix is a multiple user operating system, it's sometimes convenient to be able to momentarily switch user IDs so that you can do something as a different user than the one you're currently logged in as. To eliminate the need to log out and log back in under an alternative ID, Unix provides the su command (meaning switch user), which allows you to briefly act as another user for whom you know the login password. The su command is often used to switch to the root user ID for the purpose of performing system maintenance, but it can also be used to switch to any other user ID on the system.

The su command can be dangerous. When you are running as another user, you have all the permissions that the other user has and all of that user's capabilities. If this is another normal user on the system, you can just as easily damage his files as you can your own. If you've su'ed to the root user, you can, with a single typo of an rm command, delete every file on your drive. Table 11.6 shows the command syntax and options for the su command.

Table 11.6. The Command Syntax and Most Interesting Options for su

su	Substitute user identity.
su [-flm] [<login>] [-c <shell arguments>]
su requests the password for login and switches to that user and group ID after obtaining proper authentication. A shell is then executed, and any additional shell arguments after the login name are passed to the shell.
If su is executed with no username as an argument, root is assumed.
If su is executed by root, no password is requested, and a shell with the appropriate user ID is executed.
-c	Invoke the following command in a subshell as the specified user.
-f	If the invoked shell is csh or tcsh, this option prevents it from reading the .cshrc file. This both prevents items in the .cshrc from overriding current environment settings and can be useful if execution of the .cshrc is resource intensive or otherwise would interfere with a proper login.
-l	Simulates a full login. The environment is discarded except for HOME, SHELL, PATH, TERM, and USER. USER is set to the target login. PATH is set to "/bin:/usr/bin". TERM is imported from your current environment. The invoked shell is the target login's, and su changes directory to the target login's home directory. The -l option is synonymous with "-", as in su -.
-m	Leaves the environment unmodified. The invoked shell is your login shell; the current directory is not changed. As a security precaution, if the target user's shell is a nonstandard shell (not listed in /etc/shells), and the caller is not root, su will fail. This option is useful and is the default in many (but apparently not the Mac OS X 10.3) versions of su. Unfortunately, there are some inconsistencies in the way that this currently works. Some of the environment (your prompt, for example) is maintained unchanged without this option and changed with it, whereas other parts are maintained unchanged when -m is set and are overridden without it. Usually, we'd recommend aliasing su to su -m as the best option, but the current behavior is confusing.
The -l and -m options are mutually exclusive; the last one specified overrides any previous ones. Only users in group "wheel" (normally gid 0) or group "admin" (normally gid 20) can su to "root".
By default (unless the prompt is reset by a startup file), the super user prompt will self-modify to end with a # character to remind you of the awesome power of the root shell.

CAUTION

This does not mean that you should never use the su command. There are operations that you must perform as the root user, and you're just as likely to make some terrible mistake and mess up another user's files if you'd logged out and logged in as the other user. Respect the su command, be aware of the extra responsibility you have if you're working in someone else's account, realize the danger of careless operation as root, and you'll be fine.

Similar to the su command, the sudo command allows you to execute a single command as another user. Instead of switching user IDs and working as the other user, sudo executes a single command and returns you to working under your own ID. A particularly useful feature of sudo is that it can be configured to allow you to operate as another user without knowing that user's password. Apple has used it this way to allow admin-group users to run commands as root by using their own passwords. To make this happen, sudo's configuration is somewhat complex, requiring a complete specification of what users are allowed to run what commands, under what circumstances, and which user IDs they should appear to run these commands as when they're using them. Table 11.7 shows the command syntax and most interesting options for sudo.

Table 11.7. The Command Syntax and Most Interesting Options for sudo

sudo	Execute a command as another user.
sudo -V|-h|-l|-L|-v|-k|-K|[-H][-P][-S][-b] [-a auth_type] [-c class|-] [-p <prompt>] [-u <username>|<#uid>] <command>
sudo -V|-h|-l|-L|-v|-k|-K|[-H][-P][-S][-b] [-a auth_type] [-c class|-] [-p <prompt>] [-u <username>|<#uid>] -s | -i | -e <file> ...
sudo allows a permitted user to execute a <command> as root or another user, as specified in /etc/sudoers. The real and effective uid and gid are set to match those of the target user as specified in the passwd file or NetInfo map. By default, sudo requires that users authenticate themselves with a password. (Note: By default this is the user's password, not the root password.) After a user has been authenticated, a time stamp is updated, and the user may then use sudo without a password for a short period of time after the time stamp (five minutes unless overridden in sudoers). The time stamp is updated every time a command is executed through sudo, providing a sliding window during which the user may use commands as the alternative user without re-entering the required password. sudo determines who is an authorized user by consulting the file /etc/sudoers. By giving sudo the -v flag, a user can update the time stamp without running a command.
If a user who is not listed in /etc/sudoers TRies to run a command via sudo, mail is sent to the proper authorities, as defined at configure time or /etc/sudoers. Note that the mail will not be sent if an unauthorized user tries to run sudo with the -l or -v flags. This allows users to determine for themselves whether they are allowed to use sudo.
sudo can log attempted sudo sessions as well as errors to syslog(3), a log file, or both. By default, sudo logs via syslog(3).
When used with the -s option instead of a <command>, sudo executes the target user's shell in a manner similar to the su command. The change of effective user and execution of the shell are logged, but commands executed while in that shell are not recorded. -i is similar, with the target user's shell executed as a simulated login shell. -e <file> executes a text editor on the named file, rather than running the file as a command.
-l	Lists the allowed (and forbidden) commands for the user on the current host.
-v	Updates the user's time stamp, prompting for the user's password if necessary. This extends the sudo timeout for another five minutes (or whatever the timeout is set to in sudoers).
-k	Invalidates the user's time stamp by setting the time on it to the epoch. The next time sudo is run, a password will be required.
This option does not require a password and was added to allow a user to revoke sudo permissions from a .logout file.
-b	Tells sudo to run the given command in the background. Note that if you use the -b option, you cannot use shell job control to manipulate the process.
-S	Causes sudo to read the password from standard input instead of the terminal device.
-H	Sets the $HOME environment variable to the homedir of the target user (root by default) as specified in /etc/passwd or NetInfo. By default, sudo does not modify $HOME.
sudo TRies to be safe when executing commands. To accomplish this, most shell variables specifying load paths for dynamically loaded libraries, user paths, and similar routes by which commands may be spoofed are ignored when searching for commands and when loading dynamic modules. This will not affect general use of the sudo command, but might result in unexpected behavior in some situations. Carefully read Apple's man page for sudo (which is not quite in sync with the version of the command provided) if you experience difficulty with more sophisticated configurations.

Proper attention to configuration of the /etc/sudoers file is outside the scope of this book, but we've tried to cover the basics of the configuration in Chapter 28, where we introduce advanced security concepts. If you need to set up your machine with a sophisticated multiuser configuration that allows for cross-user sudoing, see Chapter 28, and then check out the sudoers man page. You also might want to look for Maximum Mac OS X Security, also by Will, John, and Joan Ray from Sams Publishing.

Choosing Between su and sudo: Pick Your Risk

Regarding sudo: You'll probably see many references all over the Internet to people doing this, that, or the other thing that requires root privileges, using of the sudo command instead of suing to root. In general, I disagree with this practice on a number of levels. It's okay to do this, if you want, but really, the sudo command wasn't intended, and isn't really an ideal solution for what people are using it for.

The sudo command is intended to give the root user a way to allow nonprivileged users limited access to run very specific commands with root permissions. Instead, Apple has used it as a way to allow admin users to run all commands as root.

Apple's current practice of letting an administrative user use sudo to execute any command with root privileges is just sort of a kludge that Apple has made available to get around inexperienced users needing to occasionally wear the system-administrator hat. This is okay for users who are only ever going to do one or two things as root in their use of the machine, but I don't think that the use of sudo inspires the same care as using su, where you take a separate action to actually be another user.

The real purpose of the sudo command is to allow the root user to grant the ability to access specific root-privileged commands to users who don't, and shouldn't, have full root access. Typically, this is used to allow, for example, the person who maintains the web server to restart that server, even though restarting the web server requires root privileges. The person able to do this wouldn't be given the right to do anything else as root, just to restart the web server. The sudo command isn't typically used to grant access to all commands as root, and for a user used to its traditional usage, this feels sort of sloppy. Feel free to do anything that we write as suing to root, by sudoing every command, if you feel it makes you a safer user.

In a sense, you can't forget to log out of a sued shell if you're using sudo. This makes some users, particularly inexperienced users who aren't used to paying attention to security details, into safer administrators of their machines.

In a different sense, you simply can't log out of a sudoed session. For a several-minute period after you use sudo, it'll believe that the person at the keyboard has root permissions, whether it's you sitting there or not. It'll also believe that anything run from any software that you run from the keyboard has identical privileges. A malicious gremlin hidden in an otherwise useful script could lay in wait, watching for this period of relaxed security, and then take advantage of it to do quite unpleasant things to your system.

Actually, there is a way to log out, but nobody ever shows it as part of their examples. Because of this, the normal reader is encouraged, by the uses that you'll see online and in documentation, to use sudo in a very unsafe manner. The style of use that you'll see most often used and recommended for sudo is far less safe for the conscientious user than using su. (Proper use and configuration of the sudo command to limit user access to privileged commands is covered in Chapter 28.)

The major difference for the conscientious user is that you, the conscientious user, know that you absolutely must log out of the sued shell as soon as you've accomplished what you need to do when using su. You can deauthenticate to sudo as well, but sudo deauthenticates itself after a while, and the perception, reinforced by almost all examples you'll see people giving, is that simply using sudo command and allowing it to deauthenticate itself is a safe practice. This is not the case, or at least there is no reason to assume that the lack of exploits that have been reported will continue once Apple's noncanonical use of sudo becomes more widespread.

A secondary but still significant difference is that it's easy to embed a short repetitive pattern into what is often called muscle memory. Muscle memory isn't under direct conscious control, and this generates a risk. If you're confronted with commands that require frequent use of sudo, your fingers will eventually learn to type sudo automatically, and you will find that you start using sudo <command> any time <command> might even possibly need root permission for you to run it. This gets especially risky if <command> is something like rm. If you're doing a bunch of drive cleanup and working between different users' directories, you might find that you're sudo rming a great number of files.

If you're doing this, regularly issuing sudo rm <filename> commands to accomplish some task, your fingers are going to learn this pattern, whether or not you're consciously aware of it. It's likely that the next time you want to remove a file (even not intending to be root), what will appear at the command line is sudo rm <filename>. This can create a disaster.

If your fingers learn to automatically type sudo rm and you make a typo in what you planned to rm the next time around, you can end up doing a large amount of damage to your system. There are good odds that you're going to run it sudoed, whether you intended to or not, and a single-character typo in an rm command, if run as root, can erase every file on your system.

su doesn't cause similar problems (for conscientious users) because it requires considerably more typing than sudo, and because a conscientious user becomes root, does what is necessary, and then gets back out. Even if the commands you're using get embedded in muscle memory, you're just running them as <command>, and you won't be running with root permissions if your fingertips happen to type one unrequested.

The sudo command works by initially authenticating that you really are who the shell thinks you are, and then (assuming that sudo believes your account has sufficient privileges), allowing you to run software as the root user. The sudo command then starts a timer, and if you use it again within some short time period of when you ran it last, it simply assumes that you still are who it thinks you are, and doesn't ask for your password to authenticate again. This short time period (several minutes by default) during which you can run any command with root privileges, and without entering a validating password, provides the potential for a real security problem. This opens the door for malicious software writers to embed sudoed commands into their applications that can lay in wait for some unsuspecting user to run the software within the timeout window, and then take advantage of the fact that the user has pre-authenticated to run as root.

On the other hand, using su instead of sudo is no panacea either. It's extremely easy to forget to log out of the root shell when you're finished with the parts that necessitate root access. Likewise, it's tempting to just stay in a root shell for tangential operations that don't really require root, if you think you might need the root privileges again soon. Both of these are also dangerous behaviors. The first at least can be somewhat mitigated by configuring your shell to visibly distinguish when you're running as root. The second, however, requires that you consistently place security and safety before convenience at the command line. This is not always easy to do, even for the most conscientious users.

Because of this, although both operating as root with su and operating as root with sudo have risks, the risks are different, and for any given individual, either might be the safer option. sudo's safer for users who can't or won't be bothered by being security conscious, and who would end up opening the door to their machines and then never getting around to closing them if they were using su. sudo is an automatic door closer, and will shut the door for you, but it's slow about it, and it is a short enough command that you'll find your fingers accidentally opening the door even when you didn't intend to. su's safer for users who are security conscious and who close every door they open, every time. If you don't remember to log out from sued shells, and you aren't conscientious enough to never run an unknown/unverified command or program in a sued shell, you'll eventually get bitten either by malicious software, or by a mistake in typing. If you are conscientious, the su command will never be a door for a malicious software writer to attack your machine. On the other hand, if you use the sudo command frequently, and don't use the sudo -k command to deauthenticate after each and every use, your system is vulnerable to opportunistic malicious software that can slip through the (rather large) crack during the period that sudo's holding the door open.

Right now, it probably comes down to personal preference. sudo has been around long enough that if there were any major security concerns with the sudo program itself, someone would have probably found them by now. The potential exploit of malicious scripts taking advantage of the sudo timeout period is not something that we currently see actively affecting users. This lack of activity, however, doesn't imply that the exploit won't be used in the future. I'm extremely sensitive to muscle-memory issues, having had the occasion to train my fingers to type a similar incantation as a prefix to rm to get around the per-file prompting when I was first working with Unix in 1986. This bad habit bit me badly several years later, and since then, I've become very fond of the # prompt for root. I see the # prompt, and I know I had better be darned careful about what I'm doing. I see the $ (or %, or > in other shells) prompt, and I know that I'm generally safe and can't do the system any great harm. It makes me happy and reduces my stress level. If you don't have fingers that type short commands faster than your brain can keep up, and you find worrying about logging out again when you're root more stressful, by all means, use sudo instead of suing to root. The potential problems with being sloppy with su are real, and affect users who aren't paying enough attention every day. No one needs more stress.