\"special\" shells a security hole?

[rem at remsit.UUCP]

In article <3037 at gitpyr.gatech.EDU>, robert at gitpyr.gatech.EDU (Robert Viduya) writes:
> >decot at hpisod2.HP (Dave Decot) (decot at hpisod2.HP, <2590002 at hpisod2.HP>):
> > > i've just been trying to decide whether to password some accounts on our
> > > system that run special programs instead of a normal shell.  If a program,
> > 
> > As long as it doesn't run such programs as more(1) or ex(1), either, since
> > they can be used to get someplace where a shell escape is available.  A
> > bulletin board system is rather clumsy without a text editor, but it is
> > currently impossible to tell more(1) or vi(1) to disallow shell escapes.
> 
> Actually, you can "disable" shell escapes from more(1) or ex(1) or any
> other program that follows conventions by simply setting the SHELL
> environment variable to a null program before executing the program.

What's to stop somebody from going into vi and typing ":set shell=/bin/csh"?
It's a shame they wrote red and not rvi, I think.  I'd love to set up vi for
similar reasons but can't because anyone could fork a shell (any shell they
felt like, more or less).  Of course, it's pretty silly to write a restricted
version of every program on the system (rgrep?, rawk?, rcc?, /rxenix?!? :-)

My only suggestion would be to get the source code to a reasonably good editor
and patch it for use with the BBS.  At the very worst, there is red to fall
back on.
-- 
Roger Murray

UUCP: ...!{ihnp4,randvax,sdcrdcf,ucbvax}!ucla-cs!cepu!ucla-an!remsit!rem
ARPA: cepu!ucla-an!remsit!rem at LOCUS.UCLA.EDU