Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!acornrc!bob
From: bob@acornrc.UUCP
Newsgroups: comp.sources.d
Subject: Re: Another kind of su program
Message-ID: <288@acornrc.UUCP>
Date: Wed, 11-Feb-87 02:27:27 EST
Article-I.D.: acornrc.288
Posted: Wed Feb 11 02:27:27 1987
Date-Received: Wed, 11-Feb-87 23:53:16 EST
References: <4055@caip.RUTGERS.EDU> <912@aicchi.UUCP>
Organization: Acorn Research Centre, Palo Alto, CA
Lines: 24
Keywords: su, system security
Summary: None of these schemes are secure.

I've seen all these variations on 'su' flying across the net.  None of them
are secure; they all seem to ignore the fact that once an authorized user
has superuser privileges, he can do *anything*.

For example, what's to prevent the su-ed user from copying the source to
the original su, taking out the password check, and installing the
resulting program somewhere where he can get to it later?  Or simply
writing su from scratch?  It is a trivial program, after all.  One can
even copy one's favorite shell and make it suid root.

So all one has to do is generate his own private su, make it setuid root,
and hide it somewhere in the bowels of the system.  Then if he's taken
off the authorized list, he can still su.  System administrators would have
to sweep the entire disk for setuid root programs every time a user was
de-authorized.  And I've seen complaints from people who find it a chore to
change the root password!

Bottom line: once a superuser, always -- potentially -- a superuser.

-- 
Bob Weissman
Internet:	bob@acornrc.UUCP
Usenet:		...!{ ames | decwrl | oliveb }!acornrc!bob
Arpanet:	bob%acornrc.UUCP@AMES.ARPA