Xref: utzoo alt.security:1613 alt.bbs:3019 comp.unix.sysv386:661
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!udel!haven!mimsy!prometheus!media!csense!bote
From: bote@csense.uucp (John Boteler)
Newsgroups: alt.security,alt.bbs,comp.unix.sysv386
Subject: Re: Protecting against downloads
Message-ID: <1990Sep23.061854.309@csense.uucp>
Date: 23 Sep 90 06:18:54 GMT
References: <1990Sep20.153105.28394@naitc.naitc.com>
Organization: Common Sense Computing, McLean, VA.
Lines: 48

Posting for the benefit of the trustee:

>Message-Id: <9009222103.AA06890@scicom.alphacdc.com>
>Date: 22 Sep 90 21:03:45 MDT (Sat)
>From: uunet!scicom.alphacdc.com!rick (Richard E. Oakes)
>Status: RO

> From article <2441@sud509.ed.ray.com>, by heiser@tdw201.ed.ray.com:
> > In article <epeterso.653316195@houligan> epeterson@encore.com writes:
> >>All in all, it ends up boiling down to the question "Why do you want
> >>to give your users shell access?"  To let them use the tools on the
> >>system to develop their own programs?  To learn Unix?  To experiment
> >>with various applications?  How far do you trust them?
> > What's a "public access unix" without shell access?  I want to provide
> > access for all of the reasons you mentioned here.  If I wanted to 
> > continue to ONLY allow access via a menu-driven program, I'd have no
> > reason to switch from my current dos bbs.

I came into this discussion a little late, but so far I have seen no
discussion of the oldest, but still effective way of controlling what users
do once they get to the shell: the use of /bin/rsh.  rsh does not let the user
cd to other directories, or execute commands with a path in the command (paths 
ARE allowed in the arguments), so you can controll exactly which commands they
can execute.  To implement this properly, you do need to remember a few things:

	The .profile of the user must be owned by root, and writeable ONLY by 
		root.
	The .profile must define a PATH that includes a directory such as 
		/rbin, and does NOT include /bin or /usr/bin.
	The .profile must define and export SHELL=/usr/rbin.  This will ensure
		that any shell called from vi or other programs are also rsh.
	
When you create the /rbin or similar directory, you ln any commands from 
/bin and /usr/bin that you wish the user to have unlimited access to (or
even from /usr/local, /usr/lbin, etc).  If you want to allow limited acces,
such as testing the arguments before allowing exeuction of the command, you
can write a shell script in /rbin that performs your test, then calls the
command from /bin.  For example, you might want to allow execution of the
'cat' command, but not allow reading of any file in /, /etc, /bin, or 
/usr/bin.  You write a shell script called /rbin/cat that tests its
arguments, and if they include any of the prohibited paths, send as error 
message to the user, and if not, passes the argument to /usr/bin/cat.

Richard Oakes

-- 
John Boteler   bote@csense.uucp           {uunet | ka3ovk}!media!csense!bote
SkinnyDipper's Hotline: 703-241-BARE | VOICE only, Touch-Tone(TM) signalling