Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!seismo!mcnc!gatech!cuae2!ihnp4!aicchi!ignatz
From: ignatz@aicchi.UUCP
Newsgroups: comp.sources.d
Subject: Re: Re: Another kind of su program (source)
Message-ID: <912@aicchi.UUCP>
Date: Wed, 4-Feb-87 02:40:15 EST
Article-I.D.: aicchi.912
Posted: Wed Feb  4 02:40:15 1987
Date-Received: Sun, 8-Feb-87 07:37:17 EST
References: <4055@caip.RUTGERS.EDU>
Reply-To: ignatz@aicchi.UUCP (Ihnat)
Organization: Analysts International Corp; Chicago Branch
Lines: 24
Keywords: su, system security
Summary: A secure 'su' method

A couple of years ago I ran into the problem of providing root capabilities
to several people, any one of which could disappear at any time.  I abhor
the overhead of changing the root password every time one of these people
leaves; so I don't have to do it anymore.

Simply, I re-wrote 'su' from scratch; it behaves exactly like Sys V su,
EXCEPT there's a privileged user file (/etc/privuser).  This file has a
list, one per line, of the people priviliged to become root, and an encrypted
password PER USER, similar to that in /etc/passwd.e., "ignatz:QIXPkVxTEYlYk ".
(When a user is first entered in the file by the system administrator, the
password is set to a known ASCII string by the SA.)  When that priviliged
login executes 'su', if the ASCII string is found in the privuser file,
the person must then set their root password; thereafter, until they reset
it, that's their personal root password.  Nobody except the 'real' system
administrator ever need know the 'real' root password; and revoking privileges
consists of deleting one line from the privuser file (and, as usual,
'scrubbing' the system for Trojan horses, etc.; but you always have to
do that, if you don't trust the person leaving...)  It's worked reliably
and efficiently now for 2-3 years.
-- 
	Dave Ihnat
	Analysts International Corporation
	(312) 882-4673
	ihnp4!aicchi!ignatz || ihnp4!homebru!ignatz