Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!aquarium.ecn.purdue.edu!blm From: blm@aquarium.ecn.purdue.edu (Brian L Moore) Newsgroups: comp.unix.questions Subject: Re: Who gets "root" at your site? Message-ID: Date: 3 Oct 90 00:19:48 GMT References: <1990Oct2.042650.15413@agate.berkeley.edu> <1990Oct2.133626.7573@mp.cs.niu.edu> Sender: news@ecn.purdue.edu (USENET news) Organization: Purdue University Engineering Computer Network Lines: 66 rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1990Oct2.042650.15413@agate.berkeley.edu> et@ocf.Berkeley.EDU (Eric Thompson) writes: >>#4: What do they use this access for? >> >>#5: Other info: do you have separate administrative passwords, or >> other pseudo-root logins, and how are they implemented, etc. > I created a front end command which allows those in the operator group >to execute certain commands as if they were root, but without having to >login as root. > I named the command 'RootMode', and it sits in /operator. If executed >directly it complains and exits. But if I make a hard link to it, also >in /operator, with say the name 'lpc', then anyone in the operator group >can execute /operator/lpc which just execs to the real /etc/lpc after first >becoming root. This enables those who need root privileges for special >purposes to gain them without needing to login/su as root. A syslog record >is written for each access using this facility. This works, but if you have a highly networked environment, making all of the links everywhere can be a real pain in the rear. I have modified/written a "shell" that will do this, and is *much* easier to maintain, called vss(1), "Very Secure Shell". In this, the user can "live" in the shell, as you can with su'ing or logging in as root. However, only commands that you are authorized to use as root get executed with root permissions, anything gets passed to the shell with the normal user permissions. The operation of this is controlled with 2 control files. First of all, there is a file that lists the users that may use vss(1) and any commands they may run, such as: blm reboot, shutdown, dump, restore, etc..... If the person calling vss(1) is not in this file, then vss(1) simply prints and message and exits. If they are, however, the commands they may run as root are read in. When the user tries to run one of these commands, vss(1) looks in another file to find out where the command really is... shutdown /etc/shutdown reboot /etc/reboot ... and passed the command, along with the arguments, to a shell after doing a setuid() root. If the command the user gives is not in their permission list, the command line is simply passed onto the shell and executed as the caller uid. Any commands that are run as root under this setup are logged into a third file, so someone can keep an eye on what people are using it for. With this, a person doesn't have to be in a certain group to run things as root, control files are much easier to maintain (with rdist), and tighter control is kept over who can do what. If anyone is interested in a copy of the code, send me e-mail and I will get it to you. -blm -- Brian L Moore, Student Programmer | Purdue University Engineering Computer Network | internet: blm@ecn.purdue.edu MSEE Building, Room 104 | BITNET: BMOORE@PURCCVM W. Lafayette, IN 47906 (317) 494-5745 |