Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!prls!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: \"special\" shells a security hole?
Message-ID: <658@mcgill-vision.UUCP>
Date: Fri, 20-Feb-87 09:17:16 EST
Article-I.D.: mcgill-v.658
Posted: Fri Feb 20 09:17:16 1987
Date-Received: Sun, 22-Feb-87 10:36:31 EST
References: <3953@brl-adm.ARPA> <2590002@hpisod2.HP>
Organization: McGill University, Montreal
Lines: 24

In article <2590002@hpisod2.HP>, decot@hpisod2.HP (Dave Decot) writes:
> As long as it [a special `shell' with an escape to a real shell]
> 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.

Except that the shell escaped to would be a copy of the special shell,
no?  This is certainly the case here with one program we have.  We have
an Ultrix system, which has a program dlogin to perform remote logins
over DECnet (don't ask why we're running DECnet, you don't want to
know).  We wanted a pseudo-user which just prompted for a hostname and
ran dlogin.  However, dlogin has a shell escape.  But when it's used,
all you get is another hostname prompt!

> In general, the fewer outside programs the application permits the
> user to use, the more secure such applications are.

This is pretty tough to argue with.

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!musocs!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!musocs!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu