Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (03/14/85)
Unix Technical Digest Thu, 14 Mar 85 Volume 1 : Issue 23
Today's Topics:
disallowing subshell in More (9 msgs)
----------------------------------------------------------------------
Date: 9 Feb 85 02:04:58 GMT
From: ron@men1.UUCP (Ron Flax)
Subject: disallowing subshell in More
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.
Is there a hidden option to more? Or another version or maybe an alias name,
like page to make more act a little differently?
As always thanks in advance!
Ron@men1 (Ron Flax)
MTACCS Engineering Network
..!{seismo,umcp-cs}!{prometh,cal-unix}!men1!ron
------------------------------
Date: 11 Feb 85 18:13:27 GMT
From: dave@lsuc.UUCP (David Sherman)
Subject: disallowing subshell in More
That's easy. Just muck up the environment variable SHELL and
export it to the instance of "more". Try typing
SHELL=/bin/echo more /etc/passwd
to see what I mean.
--
{utzoo pesnta nrcaero utcs}!lsuc!dave
{allegra decvax ihnp4 linus}!utcsrgv!lsuc!dave
------------------------------
Date: 12 Feb 85 00:32:38 GMT
From: cottrell@nbs-vms.ARPA
Subject: disallowing subshell in More
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.
------------------------------
Date: 12 Feb 85 04:22:44 GMT
From: geoff@desint.UUCP (Geoff Kuenning)
Subject: disallowing subshell in More
How about piping the listing into
su real-user-id -c "more"
--
Geoff Kuenning
Unix Consultant
...!ihnp4!trwrb!desint!geoff
------------------------------
Date: 12 Feb 85 20:52:00 GMT
From: vip@philabs.UUCP
Subject: disallowing subshell in More
Okay, great! You can disallow them from invoking a shell from
inside more, but can you disallow them from invoking a shell
from inside vi?
Brian
------------------------------
Date: 12 Feb 85 17:44:00 GMT
From: root%ucsce.ucscc.UUCP%Berkeley@ucscc.UUCP
Subject: disallowing subshell in 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.
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
------------------------------
Date: 12 Feb 85 13:27:59 GMT
From: jack@boring.UUCP
Subject: disallowing subshell in More
I thought I'd throw in my 10 cents worth :
Setting $SHELL is *NOT* going to work.
I remember using a games account, with SHELL set to something
funny. The way to get a shell was the following :
- Run a game that gave help.
- Ask for the helpfile (which was, of course, given to more)
- Startup 'vi' with the v command.
- do a ':set shell=/bin/sh'
- Type ':sh'
Et voila........
If you *really* want to make more secure, you should either use
chroot() to move the superuser off into the void (preferably
into a directory that cannot be reached by normal users),
or get rid of superuser permissions as soon as possible, e.g.
after opening all the files you need, do a fork(), a setuid(),
and then do with the files whatever you want.
--
Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
Notice new, improved, faster address ^^^^^
------------------------------
Date: 13 Feb 85 05:35:42 GMT
From: guy@rlgvax.UUCP (Guy Harris)
Subject: disallowing subshell in More
It's beginning to look like the law of diminishing returns is taking
effect - you might want to write a simple pager that doesn't do anything
other than page files. (I didn't even think about "more"s escape to "vi",
because I never use it - that's one problem with big programs with a large
set of features that few people are 100% familiar with.) Try "p", shown
in Kernighan and Pike starting on p. 180.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
------------------------------
Date: 12 Feb 85 17:55:00 GMT
From: dan@rna.UUCP
Subject: disallowing subshell in More
But what's wrong with setuid()'ing before exec'ing more ? That is setuid()
to the original owner, chdir if you must after the fork() but before the exec()
on more.
Or maybe you could chroot() so that /bin/sh wouldn't be found. Just put
more and vi in that directory.
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)