|< Day Day Up >|
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.
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.
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.
|< Day Day Up >|