New Messages
Please send letters via email to saletter@mfi.com.
Hello, 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/.
Johnson Earls
Greetings,
Thank you.
Carolyn Conner responds: 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.
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. Ralph Barker
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: aankerholz@mfi.com and let me know.
Thank you,
|