Thanks for all your responses. I received 18 replies by 5:00pm PDT 7/10.
Sorry I can't acknowlege you all in this summary but your responses are
greatly appreciated.
My original posting follows:
> I don't like the idea of giving the root password to each individual who
needs
> superuser priviledges. I'd rather give each individual their own superuser
> id.
> This makes indviduals more accountable for what they do with superuser
privs.
> It also prevents them from logging on to root directly.
>
> On Ultrix and OSF/1 with enhanced security turned off, this is easy; I just
> assign multiple userids to UID 0. On ULTRIX with enhanced security on, I
can't
> do that; but I can assign my "superusers" individual uids but set the shell
in
> the password file to a program that swithces the user's ruid to 0 before
> invoking their login shell. In this way, the audit logs retain the user's
> original id (auid) while running as superuser.
>
> However, on OSF/1 with enhanced security on, this changing ruid strategy
> doesn't seem to work. OSF/1 won't execute the user's login shell properly.
> It won't execute their .login or .profile. And I assume there's other
> "gotchas" that I haven't run across yet since OSF/1 security is quite a bit
> tighter that ULTRIX.
>
> How can I give selected users superuser privs without giving them direct
> access to root?
>
The answer appears to be to use the public domain program "sudo", according to
Craig I. Hagan (He was the first to respond.).
------
Steve Mclaughlin of NASA provided a source:
ftp.cs.colorado.edu:/pub/sysadmin/utilities/cu-sudo..v1.3.1pl4.tar.Z
-----
However, Richard Jackson of George Mason University adds the following caveat:
Unfortunately, it [does] not support OSF/1 2.0 and above C2 Enhanced Security.
I added code to support C2 Enhanced Security and send
sudo-bugs_at_cs.colorado.edu
the bug report and patch. They claim the code has not worked since
OSF/1 1.3.
1. cd /sys1/src/sudo-v1.3.1
2. ./configure --with-C2
3. cp -p sudo.h sudo.h.orig (modify FQDN entry ENV_EDITOR)
4. modify Makefile (change visudodir LDFLAGS)
5. modify check.c (add OSF/1 C2 passwd encryption algorithm)
6. make >& make.log&
7. make install >& make.install (strip is done automatically)
8. make clean
9. modify /etc/syslog.conf
10. kill -HUP 'syslog.pid'
11. modify sysop .cshrc aliases to use sudo
------
R.J. Robinson recommended some other sources:
ftp.isds.duke.edu in /pub/gallatin/sudo.tar.Z (might be a hacked flavor)
Try nearest gnu Archive.
----
Bradley Hughes provided a concise description of the sudo utility:
I would recommend the use of sudo for the invocation of rootly commands.
sudo takes as its argument a command line to be executed as root. sudo checks
the file /etc/sudoers, which lists the people authorised to use sudo and which
commands they are allowed to run on each host.
In other words, you can set up sudo to allow a user access to a particular
rootly command (eg. dump). When they invoke sudo, they are required to enter
their own password to authenticate the command. Sudo supports full logging
via
syslog, allowing information to be placed in the file of your choice.
Logged information is:
command line executed
person requesting command
directory from which call was made
time of invocation of command
What this means is that all root activity is logged, and access to those
system commands with the potential to compromise the system is controlled
and monitored. This is a much better situation than having several people
who know the root password and have unrestricted access to the account,
which it seems is presently the case in your situation.
------
Philip M. Howard also mentioned a modifed version available from Sysadmin
Magazine.
-------
Also, thanks to Doug McPherson, Patrick O'Brien, Jean-Loup Risler, Morton
Hanshaugen, and everyone else who responded.
Rich Siegel
siegelr_at_teleport.com
>From Beautiful Downtown Portland, OR. - where the sun really shines every once
in a while.
Received on Tue Jul 11 1995 - 07:42:59 NZST