Protecting against downloads

[Karl Denninger]

In article <1990Sep23.061854.309 at csense.uucp> bote at csense.uucp (John Boteler) writes:
>Posting for the benefit of the trustee:
>
>>Message-Id: <9009222103.AA06890 at scicom.alphacdc.com>
>>Date: 22 Sep 90 21:03:45 MDT (Sat)
>>From: uunet!scicom.alphacdc.com!rick (Richard E. Oakes)
>>Status: RO
>
>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.

NO!  This isn't going to work.

Look at ":set shell" again in vi.  Try it in this environment.  I can get
out of any environment that is controlled by "rsh" using this.

Vi has a couple of "wonderful" features in it that don't lend themselves to
security.  ":set shell" is the worst offender of all; for the user who knows
how it's a way to get to >any< executable for which the user has execute
permission.  Yes, I did say "any", and I'll stand by it.

To AT&T's credit, they don't claim that "rsh" is completely secure.  In
fact, if vi (or ex) is on the system, you may as well not bother with
"restricted" shell users.

--
Karl Denninger	AC Nielsen
kdenning at ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.