Xref: utzoo comp.unix.xenix:10192 comp.unix.i386:3055
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!texbell!sugar!ficc!morrison
From: morrison@ficc.uu.net (Brad Morrison)
Newsgroups: comp.unix.xenix,comp.unix.i386
Subject: Re: Using UUCP under a BBS system???
Message-ID: <.OV1S=Axds13@ficc.uu.net>
Date: 19 Feb 90 21:12:11 GMT
References: <2959@murtoa.cs.mu.oz.au> <511182@nstar.UUCP> <237@elrond.locus.com> <1990Feb13.214855.4265@ddsw1.MCS.COM>
Reply-To: morrison@ficc.uu.net (Brad Morrison)
Organization: Ferranti International Controls Corp. (NYSEG SCADA)
Lines: 26

In article <1990Feb13.214855.4265@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:

>The second is the killer.  Let's say you don't want people getting to the
>shell, for whatever reason.  Here's a partial list of what you can't let
>them execute (even internally as a pager or mailer):
>	vi and friends (ex, view, etc)
>	more
>	mail
>	pg
>	most other editors
>	anything with a shell escape, or anything which can chain to an editor

>Why?  Well, you'd think that "SHELL=/bin/true;export SHELL" would protect
>you from the vi ":!".  It won't.  Try ":set shell ...." sometime inside vi,
>then a ":!...." and you'll be suitably shocked.

>The same problem exists with "more"; it can chain to "vi", and from there....

>There is no way to protect from this without source code to those utilities.
>Even if you "rsh" people they can screw you using this method.  Every scheme 
>we've tried (other than removing the shell from the system!) I've been able 
>to penetrate within a few minutes; "rsh" environments included.  Only a
>"chroot" environment provides reasonable safety.

What about having a wrapper around the real shells that only execs the
real one if the user id is below some threshold?  Then give your restricted
users IDs above the threshold.
--