Path: utzoo!attcan!uunet!mcsun!ukc!tcdcs!dce.ie!em
From: em@dce.ie (Eamonn McManus)
Newsgroups: comp.unix.questions
Subject: Re: How to prevent VI from getting a shell?
Message-ID: <1990Sep19.102407.1529@dce.ie>
Date: 19 Sep 90 10:24:07 GMT
References: <501@trux.UUCP> <570@DIALix.UUCP> <1990Sep17.210110.26060@robobar.co.uk> <26243:Sep1811:57:4690@kramden.acf.nyu.edu>
Organization: Datacode Communications Ltd, Dublin, Ireland
Lines: 28

In article <26243:Sep1811:57:4690@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1990Sep17.210110.26060@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
>> I got around the problem by binary patching out the call to fork() in
>> vi.  Ugh.  Also, I never found a way to defeat letting the user read and
>> write files other than the current file.  Any offers ?
>
>A slightly brutish but correct solution is illustrated in the pty
>package. You simply convert exclamation points, colons, and other
>dangerous characters into something dull like a question mark.

This doesn't stop the user from typing Q to get into ex mode, then giving
the command `shell', unless you want to make `Q' a dangerous character.
Mapping Q to <ESC>aQ is too nasty because then you can't insert a Q at
the beginning of a line.

I think the approach of patching the binary is probably the best, in the
absence of a vi clone.  I took the vi on this system (SCO Unix, ugh) and
replaced all occurrences of the strings "sh" and "shell" with null strings
(by overwriting the first byte with 0).  You can do `SHELL=nothing vi'
and there's no way to reset the shell variable.  Now *that's* brutish. :-)

You might want to knock out the :preserve and :recover commands the same
way, for fear that the warped user could pervert them to evil ends.  And
why not nuke :read, :write, :wq, :edit, and :next while you're at it.
Am I paranoid yet?
-- 
Eamonn McManus    <em@dce.ie>    <em%dce.ie@cunyvm.cuny.edu>
	    Fingers are for fuguing.