Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.sources.d
Subject: Re: Another kind of su program
Message-ID: <665@mcgill-vision.UUCP>
Date: Fri, 20-Feb-87 10:02:17 EST
Article-I.D.: mcgill-v.665
Posted: Fri Feb 20 10:02:17 1987
Date-Received: Sun, 22-Feb-87 10:41:52 EST
References: <4055@caip.RUTGERS.EDU> <912@aicchi.UUCP> <288@acornrc.UUCP>
Organization: McGill University, Montreal
Lines: 46
Keywords: su, system security

In article <288@acornrc.UUCP>, bob@acornrc.UUCP (Bob Weissman) writes:
> I've seen all these variations on 'su' flying across the net.  None
> of them are secure;

No system with a superuser is ever really secure.  Actually, make that:
No system is ever really 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?

Absolutely nothing.  Except, of course, threat of various possible
forms of retalitory action (how'd you like to find your entire thesis
crypted?  Or just plain gone?).

> 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!

If you care enough about security to worry about "authorized" and
"unauthorized" super-users you should be sweeping for suid root
programs regularly *anyway*.  At a minimum.

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

True.  As someone else said, you can only approach a "secure" system;
such a system exists only in the limit, not in the real world.
However, you can make it fairly tough to keep su status - but you will
have quite a time stopping someone who's good enough to doctor the C
compiler as outlined by one of the Original UNIX Gurus (Ken Thompson
was it?).

What it comes down to is:  you must not, ever, give su access to any
person you can't trust with it.  Because, as you point out, once they
have it you can't stop 'em.

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!musocs!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu