Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!linus!philabs!cmcl2!seismo!brl-tgr!tgr!ucscc!root%ucsce.ucscc.UUCP@Berkeley
From: root%ucsce.ucscc.UUCP%Berkeley@ucscc.UUCP
Newsgroups: net.unix-wizards
Subject: disallowing subshell in More
Message-ID: <8279@brl-tgr.ARPA>
Date: Tue, 12-Feb-85 12:44:00 EST
Article-I.D.: brl-tgr.8279
Posted: Tue Feb 12 12:44:00 1985
Date-Received: Sat, 16-Feb-85 06:03:31 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 39


<>

>
>/*
>> Does anyone know of a way to pipe a file to more and disallow a user from
>> invoking a subshell while More is running?
>> 
>> Here's the senario, I have a menu that allows certain users to have
>	root access
>> to several functions (unjamming the print queue, archiving &
>	restoring files, 
>> etc).  One of the options is to allow the user to get a listing of a tape
>> archive to the screen (piped through More) which of course allows the user to
>> type a '!sh<return>' and viola! a root shell.
>
>One way is to pipe it to a program that:
>
>	1) calls setuid to remove root permission
>	2) exec's more
>
>Another thing to do is to set up a dummy user such as `print' which owns the
>resources such as the line printer spool ques. Even if the user manages to
>break out of your scripts, he only has access to limited resources. You
>might also investigate using the group feature, as once a user has group
>privileges he is more restricted than with owner privilege. Too many people
>resort to root owning setuid progs/scripts. It doesn't have to be this way.
>*/
>
This second suggestion might not be too cool.  It allows the user to break into
an account ('print') with more limited privileges.  There he can over-write some
program owned by 'print' with one of his own design, and wait for a super user
to happen along and run the modified program, which then has a side effect of
setting up a super user shell for the intruder.  This happened to us when we had
the 'man' command owned by a user 'manuals' and setuid.  The intruder installed
a 'man' command having the side effect of creating a setuid-root shell whenever
the super user used the 'man' command.

ucbvax!ucscc!haynes