Please send letters via email to firstname.lastname@example.org.
This letter is in response to the June 1997 article "Controlling Root," by Carolyn Conner. This is a good overview of some of the problems with root access; however, there are a couple of minor problems with the article.
First, Ms. Connor suggests that alias'ing su, the various shell names, alias, unalias, etc. is enough to prevent a user from being able to su. However, creating these aliases in no way prevents running the commands. su and the shells can always be run with a complete path (e.g., /bin/su, /bin/csh); in addition, any alias can be overcome by prefixing it with \ (e.g., \unalias su will run the real unalias command, not an alias with that name).
Second, the article implies that using /etc/hosts.equiv allows root to log in with no password. In SunOS/Solaris at least, /etc/hosts.equiv specifically does not apply to any 0-uid account. The only way to allow root to log in without a password (or to use rsh/, rcp/, etc.) is to create a /.rhosts file.
I'd also like to note that one additional solution to limiting root access via su is to compile a BSD4.3-style su program, which requires that a user be part of group 0 ("wheel" or "root") in order to su to a 0-uid account. The source for the su from 4.3bsd-reno is available at http://wuarchive.wustl.edu/systems/unix/4.3bsd-reno/usr.bin/su/ - although you will probably have to disregard the makefile there and compile the source on your own. Another option: the sudo program makes a nice addition to a restricted su; sudo allows certain users to run specific commands as root, without actually giving them a root shell. sudo may be obtained from ftp://ftp.courtesan.com/pub/sudo/.
I would like to comment on the article "Controlling Root," in the June 1997 issue. I am surprised that the author did not mention the sudo package. sudo would allow users access to certain root-controlled programs without necessarily giving the users the root password. In some situations it can be a very good compromise.
Carolyn Conner responds:
My attempt to prevent logons from su'ing by alias'ing su is effective only in an environment of inexperienced UNIX users. Fortunately, I have received several good suggestions for preventing generic logons from su'ing to other accounts in the SUN Solaris environment.
I do not know anything about sudo program, but am anxious to try it. Below are two more good suggestions that I received from readers.
The first suggestion requires the creation of a new group named "susers" (the name is just an example). The group of the su program should then be changed to "susers" and the world read and execute permissions removed. This allows only root and the members of group "susers" the ability to run su.
The second suggestion requires the creation of a new group named "nosusers" (again, the name is just an example). The group of the su program should then be changed to "nosusers" and the group read and execute permissions removed. This allows anyone except the logons in the "nosusers" group the ability to run the su program.
If "susers" or "nosusers" is the primary group of the restricted logons, there should be no problem. If, however, they are secondary groups of the restricted logons, the choice of method between "susers" and "nosusers" would depend on which group had the least number of users. Care must be taken so that the "susers" or "nosusers" line in /etc/group does not exceed the length limit, which would cause /etc/group file corruption. This corruption is easily corrected, but can cause big problems.
Concerning the second point in Johnson Earls' letter, I did not make clear that root access is handled as a special case. Only the .rhosts file is checked when remote access is being attempted for root.
I really appreciate the feedback and look forward to hearing from you again.
Thank you for finally realizing that NT must be integrated into Sys Admin. We have a SCO box and are running NT on a Compaq server. I have always been a UNIX man myself but am now forced into the NT role as well. I have found that a great many other companies have gone the NT route also, but I think there will always be room for UNIX. The NT element was the thing I was looking for - the May issue made me decide to get my own subscription to Sys Admin ( I had been reading my friend's subscription for a while now). Keep up the good work, and I am looking forward to reading more about UNIX/NT integration.
David M. Buyer Jr.
CEO, DMB Consulting
Based on our reader surveys, your dual-OS situation is becoming increasingly common.We appreciate your comments and will continue to make our best effort at fulfilling your technical information needs on system administration topics, both UNIX and Windows NT.
Many readers have recently emailed me requesting Sys Admin's author guidelines. I'm happy to provide this information, but in the interest of serving you better, we've also made the guidelines available on our Web site. The URL for our site is: http://www.samag.com.
Other items of interest on the site include: Sys Admin CD-ROM (containing all articles from 1992-1995) order form, back issue listings, and the source code archives. If you have suggestions for other information you think should be added, please email me at: email@example.com and let me know.
Managing Editor, Sys Admin