Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!mordor!jdb
From: jdb@mordor.UUCP
Newsgroups: comp.unix.wizards,comp.unix.questions,comp.bugs.4bsd
Subject: Re: su modifications posted to net.sources
Message-ID: <1599@mordor.s1.gov>
Date: Thu, 5-Feb-87 11:22:09 EST
Article-I.D.: mordor.1599
Posted: Thu Feb  5 11:22:09 1987
Date-Received: Sat, 7-Feb-87 11:59:33 EST
References: <160@quacky.mips.UUCP>
Reply-To: jdb@mordor.UUCP (John Bruner)
Organization: S-1 Project, LLNL
Lines: 19
Xref: watmath comp.unix.wizards:842 comp.unix.questions:925 comp.bugs.4bsd:174

In general, you do NOT want "su" to search an "/etc/su_people".
Having such a file multiplies the number of accounts which must
be secured against intrusion.  It is difficult enough to protect
one account (root).  With N entries in "/etc/su_people" there are
(effectively) N root accounts which can be attacked.  It is much
harder to protect N passwords, N accounts' files, etc. than it is
to protect a single root password and the system directories.

[If you're using NFS, such a change is suicidal.  NFS as distributed
from Sun [even in release 3.2] can be compromised to allow a local
user to read/write any non-root-only file (on an exported filesystem).
It is easy to create a mode 4755 file owned by anyone (except
root), which can be used to get a shell running under any user-id
(bad enough), which can be used to get a root shell via a
permissive "su".]
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor.s1.gov		(415) 422-0758
  UUCP: ...!ucbvax!decwrl!mordor!jdb 	...!seismo!mordor!jdb