Xref: utzoo alt.security:1533 alt.bbs:2923 comp.unix.sysv386:353
Path: utzoo!utgpu!cs.utexas.edu!asuvax!mcdphx!udc!neutrino.urbana.mcd.mot.com!gwhisen
From: gwhisen@neutrino.urbana.mcd.mot.com (Gary Whisenhunt)
Newsgroups: alt.security,alt.bbs,comp.unix.sysv386
Subject: Re: Protecting against downloads
Message-ID: <1385@urbana.mcd.mot.com>
Date: 13 Sep 90 19:37:08 GMT
References: <22@tdw205.ed.ray.com>
Sender: netnews@urbana.mcd.mot.com
Reply-To: gwhisen@neutrino.urbana.mcd.mot.com (Gary Whisenhunt)
Lines: 36


In article <22@tdw205.ed.ray.com>, heiser@sud509.ed.ray.com (Bill Heiser
- Unix Sys Admin) writes:
|> 
|> A *ix sysop I communite with recently told me that he'd caught one of
|> his "shell-access" users downloading *ix binaries.  Since I'm getting
|> ready to set up my system for public access, this concerns me.  How
|> do you all who run public-access systems protect yourselves against this
|> kind of thing?  If it went on for long enough, the person could get 
|> himself an entire OS for free!!
|> 
|> As far as I can see, we either have to trust the users that we give
|> shell access to, or make kermit/sz, etc unavailable to them.  I guess
|> we could just make downloads only available thru the "bbs", rather than
|> from the shell ...
|> 
|> Anyone else have any ideas on this?  How do you all deal with this?

Change the mode of the binaries that you want to protect to:

	-r-x--x--x

(assuming that they people using this are not the owners of the binaries
which they shouldn't be)

so that people can execute them but can't read them.

You also need to ensure that you can't ptrace one of these executables,
otherwise you can very slowly make copies of the executing images.
I can't really remember which variants of UNIX closed this door.


Gary Whisenhunt
Motorola Inc., MCD - Urbana		gwhisen@urbana.mcd.mot.com
1101 E. University Avenue		..!uiucdcs!udc!gwhisen
Urbana, IL 61801