Who gets "root" at your site?

[Brian L Moore]

rickert at mp.cs.niu.edu (Neil Rickert) writes:

>In article <1990Oct2.042650.15413 at agate.berkeley.edu> et at 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 at ecn.purdue.edu
MSEE Building, Room 104                        |  BITNET: BMOORE at PURCCVM
W. Lafayette, IN  47906      (317) 494-5745    |