car@trux.UUCP (Chris Rende) (09/12/90)
If I want to give someone access to VI and yet deny them access to a shell, how do I prevent the user from using VI's "<ESC>:!" command? I have an application program which launches VI. I don't want the user to be able to get to a shell from VI. (I also don't want the user to be able to launch other commands from VI. I.e., No :!pwd, or !!sort, etc...). car. -- Christopher A. Rende Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3) uunet!edsews!rphroy!trux!car Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1 trux!car@uunet.uu.net Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF trux!ramecs!car "I don't ever remember forgetting anything." - Chris Rende
bernie@DIALix.UUCP (Bernd Felsche) (09/15/90)
In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >If I want to give someone access to VI and yet deny them access to a shell, >how do I prevent the user from using VI's "<ESC>:!" command? > >I have an application program which launches VI. I don't want the user to >be able to get to a shell from VI. (I also don't want the user to be able >to launch other commands from VI. I.e., No :!pwd, or !!sort, etc...). set SHELL in the environment to something which doest nothing, say /bin/true. vi forks-execs whatever SHELL is defined to be, or the shell if undefined. Many applications allow SHELL escapes, and cause security holes because they don't set the real user id before they shell-off. Some time ago I wrote a shell-wrapper which did the right thing before allowing the user a real shell. The application program also required a wrapper to set SHELL to the shell-wrapper. bernie
omerzu@quando.quantum.de (Thomas Omerzu) (09/17/90)
In article <570@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: >In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >>If I want to give someone access to VI and yet deny them access to a shell, >>how do I prevent the user from using VI's "<ESC>:!" command? > >set SHELL in the environment to something which doest nothing, say >/bin/true. vi forks-execs whatever SHELL is defined to be, or the >shell if undefined. NO! Although this will work for many applications, it won't work for vi! If you 'set SHELL /bin/true' the user will not be able to get a shell, that's true. BUT: THIS DOES NOT PREVENT THE USER FROM RESETTING THE SHEL VARIABLE! If that user does a: ':set shell /bin/sh' he _will_ get a shell on further requests!!! So long, Thomas. -- *-----------------------------------------------------------------------------* Thomas Omerzu UUCP: ...!unido!quando!omerzu / omerzu@quando.uucp Quantum GmbH, Bitnet: UNIDO!quando!omerzu / omerzu%quando@UNIDO(.bitnet) Dortmund, Germany Internet: omerzu@quando.quantum.de
jrw@mtune.ATT.COM (Jim Webb) (09/17/90)
In article <570@DIALix.UUCP>, bernie@DIALix.UUCP (Bernd Felsche) writes: > In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: > >If I want to give someone access to VI and yet deny them access to a shell, > >how do I prevent the user from using VI's "<ESC>:!" command? > > set SHELL in the environment to something which doest nothing, say > /bin/true. vi forks-execs whatever SHELL is defined to be, or the > shell if undefined. True, but..... $ SHELL=/bin/true ex # ex is easier to deal with here :-) :sh # run a shell.... ! # comes right back :set shell=/bin/sh # hmmm.... :sh # now what can I do.... $ Later, -- Jim Webb "Out of Phase -- Get Help" att!mtune!jrw "I'm bored with this....Let's Dance!"
ronald@robobar.co.uk (Ronald S H Khoo) (09/18/90)
In article <570@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: > set SHELL in the environment to something which doest nothing, say > /bin/true. vi forks-execs whatever SHELL is defined to be, or the > shell if undefined. I don't know about *your* version of vi, but mine lets you defeat this by doing :set shell=/bin/sh 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 ? -- my .signature is on holiday
rda353l@monu6.cc.monash.edu.au (a.r. 8947277 baxter) (09/18/90)
bernie@DIALix.UUCP (Bernd Felsche) writes: >In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >>If I want to give someone access to VI and yet deny them access to a shell, >>how do I prevent the user from using VI's "<ESC>:!" command? >set SHELL in the environment to something which doest nothing, say >/bin/true. vi forks-execs whatever SHELL is defined to be, or the >shell if undefined. Um, no. You can also type '<ESC>:set shell=/bin/sh' inside vi, then shell out as you would normally. One way to stop shelling out is to get the source for elvis or some other vi-clone, then remove the shell-out facility. You also might want to disable the '<ESC>:r' and '<ESC>:w' commands, to stop people getting copies of files which they are not meant to see. There may be some other way to stop shelling out, I dont claim to be an expert on vi. Anthony Anthony Baxter: rda353l%monu6.cc.monash.oz@uunet.UU.NET Robotics and Digital Technology {uunet}!munnari!monu6.cc.monash.oz!rda353l Monash University, Caulfield
dylan@ibmpcug.co.uk (Matthew Farwell) (09/18/90)
In article <1990Sep17.210110.26060@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >In article <570@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: >> set SHELL in the environment to something which doest nothing, say >> /bin/true. vi forks-execs whatever SHELL is defined to be, or the >> shell if undefined. >I don't know about *your* version of vi, but mine lets you defeat this >by doing :set shell=/bin/sh >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 ? #ifdef PLUG_ELVIS You install elvis, like I will when I get around to it + people who know how to break vi have a go at breaking it. (subtle hint ron). Elvis is nice + easy to disable commands. I actually quite like it. #endif Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| ...!uunet!ukc!ibmpcug!dylan Harrow HA1 4LQ England | CONNECT - Usenet Access in the UK!! Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/18/90)
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. % pty -0 tr \!: \?\? | pty vi The only problem is that the user can't even type ! or : any more! To kludge around this, convert ! into <esc>a! and : into <esc>a:. You should also provide macros (not using ! or :) to allow whatever restricted : commands the user might reasonably want. This does, however, solve the stated problem. (Be sure to disable keyboard interrupts, by the way.) ---Dan
jmm@eci386.uucp (John Macdonald) (09/18/90)
In article <570@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: |In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: |>If I want to give someone access to VI and yet deny them access to a shell, |>how do I prevent the user from using VI's "<ESC>:!" command? |> |>I have an application program which launches VI. I don't want the user to |>be able to get to a shell from VI. (I also don't want the user to be able |>to launch other commands from VI. I.e., No :!pwd, or !!sort, etc...). | |set SHELL in the environment to something which doest nothing, say |/bin/true. vi forks-execs whatever SHELL is defined to be, or the |shell if undefined. Sorry, that is insufficient. A user can just use the vi command ":set SHELL=/bin/sh" to change it to something usable. The only way to prevent shell access is to patch vi to prevent it. A copy of vi should be used, call it rvi or some such so that it doesn't get used by trusted users by mistake. Figuring out what has to be patched to disable all possible shell invokations is still a significant effort - and is specific to the particular machine you are running on - and will be a lot of work to figure out [easy to do afterward] - and you may still wonder whether you missed any variants [e.g. read and write have variants to run a program instead of using a file]. Perhaps a better solution would be to provide a more limited editor that is easier to check for any external command capability, if you can find one. -- Algol 60 was an improvment on most | John Macdonald of its successors - C.A.R. Hoare | jmm@eci386
domo@tsa.co.uk (Dominic Dunlop) (09/18/90)
In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >If I want to give someone access to VI and yet deny them access to a shell, >how do I prevent the user from using VI's "<ESC>:!" command? And several people have said: 1. Set SHELL=/bin/true in the environment (no good -- can :set shell from with vi) 2. Get public domain vi (like elvis) and hack out the :sh and :! code. 3. As 2, but hack out code for :r to read and :w to write arbitrary files. This begins to be usefully restrictive (if such a concept can be entertained), but I'll add the following further points: 4. Disable :r !command, to run an arbitrary command and capture its output in the edit buffer; and w !command to write all or part of edit buffer through an arbitrary command. 5. Also disable :e and :n (edit arbitrary files), :fi (change name of file to which vi will write), and :cd command (where it gets written if its name is not a full pathname). 6. Disable !<multi-line motion>command which passes the lines selected by <multi-line motion> through an arbitrary command, and replaces them with the output of the command. While you can't get interactive shells with some of these, you can easily hand off scripts to shells and do arbitrary things to arbitrary files. Bottom line? You'll have to break vi exceptionally comprehensively to block all the loopholes. And, talking of breaking things (did I say that?): Incidentally, the IEEE 1003.2 working group, in its User Portability Extension, is standardizing vi. The current draft of the proposed standard specifies a new option, -n, to ``disable or restrict editor features, so that the vi utility can be used in a more secure manner. The features affected are the sh and ! commands, which shall be disabled completely, and all commands taking a pathname as an argument, for which absolute pathnames and relative pathnames containing a dot-dot ("..") element shall be disallowed.'' The standardized vi incorporates colon escapes into ex in the time-honoured manner. Both vi and ex implement shell-spawning actions introduced by exclamation points. The description of ex also calls out a -n option, with a description identical to that for vi. In both cases it appears that the security holes introduced by actions involving exclamation points have been overlooked. Damn. Maybe I should tell someone. -- Dominic Dunlop
les@chinet.chi.il.us (Leslie Mikesell) (09/19/90)
In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >If I want to give someone access to VI and yet deny them access to a shell, >how do I prevent the user from using VI's "<ESC>:!" command? >I have an application program which launches VI. I don't want the user to >be able to get to a shell from VI. (I also don't want the user to be able >to launch other commands from VI. I.e., No :!pwd, or !!sort, etc...). Sorta defeats the purpose of using vi unless you really don't have any useful programs to :r !command or :w !command. But, if that's what you want, why not build a suitable environment in a subdirectory (TMPDIR, vi itself, etc.) and chroot() before starting vi. It's hard to hurt anything if you can't get there. Les Mikesell les@chinet.chi.il.us
ronald@robobar.co.uk (Ronald S H Khoo) (09/19/90)
In article <1990Sep18.071435.6357@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: >#ifdef PLUG_ELVIS #undef PLUG_ELVIS Elvis is unuseable over a slow modem line -- it scrolls sideways therefore it repaints the screen continuously as you go back and forth on a long line. No thanks. -- my .signature is on holiday
em@dce.ie (Eamonn McManus) (09/19/90)
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.
darryl@lemuria.MV.COM (Darryl Wagoner) (09/19/90)
In article <501@trux.UUCP> car@trux.UUCP (Chris Rende) writes: >If I want to give someone access to VI and yet deny them access to a shell, >how do I prevent the user from using VI's "<ESC>:!" command? >I have an application program which launches VI. I don't want the user to >be able to get to a shell from VI. (I also don't want the user to be able >to launch other commands from VI. I.e., No :!pwd, or !!sort, etc...). I am not sure how secure it is, but the simple way is to change the "SHELL" environment variable to something like "true(1)". This works for both <ESC>:! and !!command. Good luck -Darryl -- Darryl Wagoner darryl@lemuria.MV.COM or uunet!virgin!lemuria!darryl 12 Oak Hill Road Brookline, NH 03033 Office: 603.672.0736 Home: 603.673.0578
shwake@raysnec.UUCP (Ray Shwake) (09/20/90)
ronald@robobar.co.uk (Ronald S H Khoo) writes: >I don't know about *your* version of vi, but mine lets you defeat this >by doing :set shell=/bin/sh >I got around the problem by binary patching out the call to fork() in vi. I suggest that, after predefining SHELL to something innocuous (I use /bin/echo), patch the *set* reference in the binary to something with an embedded space. So far, its proven quite tight. (Of course, if even THIS leaves some obscure weakness, I'm sure someone will point it out to me!)
jeff@onion.pdx.com (Jeff Beadles) (09/20/90)
In article <570@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: >set SHELL in the environment to something which doest nothing, say >/bin/true. vi forks-execs whatever SHELL is defined to be, or the >shell if undefined. >Many applications allow SHELL escapes, and cause security holes >because they don't set the real user id before they shell-off. Some >time ago I wrote a shell-wrapper which did the right thing before >allowing the user a real shell. The application program also >required a wrapper to set SHELL to the shell-wrapper. Bleep. Wrong answer. Take vi, for example... You can set "SHELL" to be whatever you desire. However, from within vi, you can use ":set shell=/bin/sh" and be on your merry way. There's no easy way to prevent shell escapes like this without The Source. -Jeff -- Jeff Beadles jeff@onion.pdx.com
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <1990Sep19.102407.1529@dce.ie> em@dce.ie (Eamonn McManus) writes: > 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. No, that is *not* a problem. In the EXINIT, simply map Q to something else. You can also do this to !---but not to :, which is why you have to use the pty solution. > 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. Fgs. This is why you want to nuke : entirely, then start adding macros from a clean slate. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <1990Sep18.204300.25376@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > Sorta defeats the purpose of using vi unless you really don't have any > useful programs to :r !command or :w !command. That's why you set up macros to invoke the special, secure, cases that users really want. fmt, for example. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <1990Sep18.163019.14294@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: > The only > way to prevent shell access is to patch vi to prevent it. This just isn't true. All you have to do is break the user's !, Q, and : keys. This turns from a joke into an easy pipe if you have pty. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <77@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: > I suggest that, after predefining SHELL to something innocuous (I use > /bin/echo), patch the *set* reference in the binary to something with an > embedded space. So far, its proven quite tight. (Of course, if even THIS > leaves some obscure weakness, I'm sure someone will point it out to me!) The problem is that it completely prevents useful things like :set nu. ---Dan
bernie@DIALix.UUCP (Bernd Felsche) (09/21/90)
Well, so much for my suggestion about setting SHELL=/bin/true. My suggestion was made on the spur of the moment, without consideration for the :set shell=/bin/wizard feature. Mind you, the SHELL trick does make it inconvenient, if not impossible for casual users (Who knew about "set shell=" before following this thread of discussion?) I was not under the impression that a _secure_ environment was required. As Dominic Dunlop of TSA points out, vi with all the shell escape stuff disable is of limited use (IMHO:stuffed) There are many unix editors with source code in the public domain or available at no charge. Any of these could be knobbled to prevent all but rudimentary editing. In the mean time, why not use cat? :-) In the case of a "secure" environment, users would be operating in a chroot environment anyway... with a limited subset of commands... only able to harm themselves. bernie
dylan@ibmpcug.co.uk (Matthew Farwell) (09/22/90)
In article <13775:Sep2104:58:1490@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >This just isn't true. All you have to do is break the user's !, Q, and : >keys. This turns from a joke into an easy pipe if you have pty. Or you could use a hammer to break their ! and Q keys. That usually works Then they can't use them at all. Even better break their fingers then they can't type at all. Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| ...!uunet!ukc!ibmpcug!dylan Harrow HA1 4LQ England | CONNECT - Usenet Access in the UK!! Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
shwake@raysnec.UUCP (Ray Shwake) (09/24/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <77@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >> I suggest that, after predefining SHELL to something innocuous (I use >> /bin/echo), patch the *set* reference in the binary to something with an >> embedded space. So far, its proven quite tight. (Of course, if even THIS >> leaves some obscure weakness, I'm sure someone will point it out to me!) >The problem is that it completely prevents useful things like :set nu. Ah, but the whole point of this exercise is to deny one functional option (access to the shell) with minimal untoward effects. I could, of course, argue that those who have no business in the shell are not the sort who should be mucking about with "set" variables, or that those variables could be pre-set before firing up VI. Those suggesting non-standard, and unsupported alternatives like 'elvis' or 'pty' patches take us into uncharted territories. Mucking about with standard ASCII characters like Q, ! and :, and then trying to compensate for such a kludge is a definite no-no in THIS wizard's environment.
toma@ozdaltx.UUCP (Tom Armistead) (09/28/90)
Boy - am I brave posting this - or was it stupid? I forget...
Here is a real small C program that will batch the /usr/bin/vi, creating
an output file ./vi.new that will not have the ':set shell' command.
What it does is look for 'shell' and replace it with 5 spaces. So,
':set shell' gives an error...
Anyway, you can move vi to vi.orig and remove execution priv's from it
and move vi.new to /usr/bin/vi.
p.s. This works on System V machines (not tested on anything else).
-----------------------------CUT HERE----------------------------------
/*************************************************************************
** fixvi.c
** Description:
** This program will create the executable file specified by VI_OUT
** and remove the ':set shell' command from it.
** Disclaimer:
** This program is hereby released as PUBLIC DOMAIN.
** It comes with ABSOLUTELY NO warranty...
**************************************************************************/
#include <sys/types.h>
#include <sys/stat.h>
#include <malloc.h>
#include <string.h>
#include <fcntl.h>
#define VI_IN "/usr/bin/vi" /* original version of vi */
#define VI_OUT "./vi.new" /* new version (with shell) */
main()
{
struct stat sbuf; /* to get size of file VI_IN */
char *read_buf=(char *)0; /* read VI_IN into here */
register char *bufptr; /* pointer into read_buf */
register rdlen; /* read return value */
register int i; /* You know? */
int fdin=(-1), fdout=(-1); /* file descriptors for read/write */
/***********************************************************************
** Stat VI_IN to get it's size, the open it for reading.
** Create VI_OUT (will contain modified version of VI_IN
************************************************************************/
if( stat( VI_IN, &sbuf ) != -1 &&
(fdin=open( VI_IN, O_RDONLY )) != -1 &&
(fdout=open( VI_OUT, O_WRONLY|O_CREAT|O_TRUNC )) != -1 )
{
/********************************************************************
** Malloc area large enough to hold entire file VI_IN.
** Read entire file VI_IN into the malloc'd buffer.
*********************************************************************/
if( (read_buf=malloc( (unsigned)sbuf.st_size+1 )) != (char *)0 &&
(rdlen=read( fdin, read_buf, (unsigned)sbuf.st_size )) ==
sbuf.st_size )
{
/*****************************************************************
** Look through buffer for all occurrences of the string 'shell'
** and replace each one with 5 spaces.
******************************************************************/
for( bufptr=read_buf; bufptr < read_buf+rdlen; bufptr++ )
if( *bufptr == 's' && !strncmp( bufptr, "shell", 5 ) )
for( i=0; i<5; i++ )
*(bufptr++) = ' ';
/*****************************************************************
** Write out modified version of VI_IN to VI_OUT. This will be
** the vi that has no 'set shell' command.
******************************************************************/
if( write( fdout, read_buf, rdlen ) != rdlen )
perror( "write" );
}/*end if malloc*/
}/*end if open()*/
else
perror( "open" );
if( read_buf != (char *)0 ) free( read_buf );
if( fdin != -1 ) close( fdin );
if( fdout != -1 ) close( fdout );
chmod( VI_OUT, 0555 ); /* chmod +rx-w VI_OUT */
}/*end main*/
/*end fixvi.c*/
--
-------------------------------
{uunet,smu,ames}!sulaco!ozdaltx!toma (Tom Armistead @ Garland, Texas)
{mic,void,egsner}!ozdaltx!tomaem@dce.ie (Eamonn McManus) (10/01/90)
In article <7007@ozdaltx.UUCP> toma@ozdaltx.UUCP (Tom Armistead) writes: >Here is a real small C program that will batch the /usr/bin/vi, creating >an output file ./vi.new that will not have the ':set shell' command. >What it does is look for 'shell' and replace it with 5 spaces. So, >':set shell' gives an error... Vi also allows `:set sh' as an abbreviation for `:set shell'.