Major security problem in the UA: looking for a real fix

[Darryl P. Wagoner]

In article <794 at umbc3.UMD.EDU> alex at umbc3.UMD.EDU (Alex S. Crain) writes:
>
>	A large hidden issue is this: If a system admin closes all the holes
>that he knows about, then he won't have any idea how the hacker broke his 
>system. So this approch doesn't work.

I am sorry that statement doesn't track.  If you don't close all of the
holes that you know about then you won't know if the hacker got in via
the one you know about or another one.


>	The stock solution, regularly used for anonymous ftp, is to have
>two groups of users, trusted and not trusted. Trusted users are given a free
>run of the system, non-trusted users (guest logins, etc) get a restricted
>shell and very limited access to the system (see rsh(1)). Since a 3b1 will
>only support a few users, this should work for most cases, and after all,
>If I don't trust someone enough to think that he won't trash my system, who
>cares if he gets windows or not?

Don't trust rsh(1) to work the way you would hope.  It is childs play for
any hacker worth his salt to break out of the rsh(1).  chroot(1M) is the
best way to contain a user, but beware it has a few risks itself.  Mainly
because you must have and protect the /chroot/etc directory the same 
as you would the real one.


On the problem of UA, one solution maybe a program that will check out
what the user is passing to uasetx & uasig and reject or accept it base 
upon the user, the group that user, and where he is logged in.  Uasig
may not be a problem, but it is a setuid program and should be checked
out.  At some point I may write this program but it will be a while.

-- 
Darryl Wagoner		dpw at unisec.usi.com
UniSecure Systems, Inc.; 			OS/2, Just say No!
Round Rock,  Tx; (512)-255-8751 (home) (512)-823-3774
UUCP:  {ut-sally!uiucuxc!kitty}!unisec!dpw