\"special\" shells a security hole?

[robert at gitpyr.UUCP]

>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,
> > e.g. a bulletin-board system, does not allow shell escapes is it relatively
> > secure even if it doesn't run in a chroot'd environment?
> 
> 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.
I'd recommend /bin/true, but vi(1) on our system doesn't seem to like
shell scripts as shells;  an alternate could be /bin/sync, which is
another command that ignores arguments, returns a "good" status and
doesn't do anything apparent to the user.  This is a kludge, true, but
it works and can be quite valuable if you are a binary-only site.

Watch out for programs that allow shell escapes but ignore SHELL, though.
I don't know of any that do, but that doesn't mean they don't exists.
They're anti-social anyway.

			robert
-- 
Robert Viduya					     robert at pyr.ocs.gatech.edu
Office of Computing Services					(404) 894-4660
Georgia Institute of Technology
Atlanta, Georgia	30332