UNIX System Administration Handbook - Evi Nemeth [34]
You should change the root password
• At least every three months or so
• Every time someone who knows the password leaves your site
• Whenever you think security may have been compromised
• On a day you’re not planning to party so hard in the evening that you will have forgotten the password the next morning
3.4 BECOMING ROOT
Since root is just another user, you can log in directly to the root account. However, this turns out to be a pretty bad idea. To begin with, it leaves no record of what operations were performed as root. That’s bad enough when you realize that you broke something last night at 3:00 a.m. and can’t remember what you changed; it’s even worse when the access was unauthorized and you are trying to figure out what an intruder has done to your system. Another disadvantage is that the log-in-as-root scenario leaves no record of who was really doing the work. If several people have access to the root account, you won’t be able to tell who used it when.
For these reasons, most systems allow root logins to be disabled on terminals and across the network—everywhere but on the system console. We suggest that you use these features. See Secure terminals on page 660 to find out what file you need to edit on your particular system.
su: substitute user identity
The su command can also substitute identities other than root. Sometimes, the only way to reproduce or debug a user’s problem is to su to their account so that you reproduce the environment in which the problem occurs. If you know someone’s password, you can access that person’s account directly by executing su username. As with an su to root, you will be prompted for the password for username. On some systems, the root password will allow an su or login to any account. On others, you must first su explicitly to root before suing to another account; root may su to any account without providing a password. It’s a good idea to get in the habit of typing the full pathname to the su command (e.g., /bin/su or /usr/bin/su) rather than relying on the shell to find the command for you. This will give you some protection against programs called su that may have been slipped into your search path with the intention of harvesting passwords.4 On many systems, you must be a member of the group “wheel” in order to use su. sudo: a limited su Our solution to these problems is a program called sudo that is currently maintained by Todd Miller (who was also a contributor to this book). It’s available from www.courtesan.com. sudo takes as its argument a command line to be executed as root (or as another restricted user). sudo consults the file /etc/sudoers, which lists the people who are authorized to use sudo and the commands they are allowed to run on each host. If the proposed command is permitted, sudo prompts for the user’s own password and executes the command. Additional sudo commands may be executed without the “sudoer” having to type a password until a five-minute period (configurable) has elapsed with no further sudo activity. This timeout serves as a modest protection against users with sudo privileges who leave terminals unattended. sudo keeps a log of the command lines that were executed, the people who requested them, the directory from which they were run, and the times at
A slightly better way to access the root account is to use the su command. If invoked without any arguments, su will prompt you for the root password and then start up a root shell. The privileges of this shell remain in effect until the shell terminates (via
Since the privileges of the superuser account cannot be subdivided, it is hard to give someone the ability to do one task (backups, for example) without giving that person free run of the system. And if the root account is used by several administrators, you really have only a vague idea who’s using it or what they’ve done.