ron@men1.UUCP (Ron Flax) (02/09/85)
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
"The opinions expressed herein are mine only if you agree with them."Ron Natalie <ron@BRL-TGR> (02/11/85)
Just zap the SHELL environment variable to something that is unexecutable (be sure that it isn't something that the user can put an executable file into however). More then will say "exec failed" at any attempt to use the ! feature. -Ron
mikeh@haddock.UUCP (02/11/85)
Hi there, Just a thought, more(1) uses the enviornment variable $SHELL to determine what shell to invoke. The root id caller of more sets SHELL to an innocuous program the hole vanishes. I would overimplement and have the $SHELL program setuid and setgid to the user and then exec the users faviorite shell, but setting $SHELL to /bin/true would probably work. Not, what holes are in my scheme? mike & Herbie
dave@lsuc.UUCP (David Sherman) (02/11/85)
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!davecottrell@nbs-vms.ARPA (02/12/85)
/* > 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. */
geoff@desint.UUCP (Geoff Kuenning) (02/12/85)
In article <362@men1.UUCP> ron@men1.UUCP (Ron Flax) writes: >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. How about piping the listing into su real-user-id -c "more" -- Geoff Kuenning Unix Consultant ...!ihnp4!trwrb!desint!geoff
jack@boring.UUCP (02/12/85)
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 ^^^^^root%ucsce.ucscc.UUCP%Berkeley@ucscc.UUCP (02/12/85)
<> > >/* >> 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
dan@rna.UUCP (02/12/85)
x > 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. 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.
vip@philabs.UUCP (02/12/85)
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
guy@rlgvax.UUCP (Guy Harris) (02/13/85)
> 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........ 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
vip@philabs.UUCP (02/14/85)
>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 >/* ---------- */ Okay, Guy, great. But what if you want your users to use a program like vi? Then what? I would like users to be able to use an editor. Vi and most other editors, with the exception of some of the third-party (expensive) stuff, allow the user to escape to a shell. Brian M. Day philabs!exquisit!brian
guy@rlgvax.UUCP (Guy Harris) (02/14/85)
> >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. > > Okay, Guy, great. But what if you want your users to use a program like > vi? Then what? I would like users to be able to use an editor. Vi and > most other editors, with the exception of some of the third-party > (expensive) stuff, allow the user to escape to a shell. To quote from the original article: > 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. Either the operator won't want to use "vi" to look at the listing, in which case this isn't a problem, or they do, in which case they can't do it without buying or writing an editor (or browser) which forbids spawning shells. Life's tough. I wasn't advocating throwing "more" out; I was advocating replacing the pager in this particular example with something simpler. Perhaps a simple browser (a read-only screen "editor", in effect; "editor" is really a misnomer) would be what's called for. The point of my comment is that one problem with feature-rich tools is that nobody may understand them fully, and may get bitten by a hidden side-effect (like being able to do the "more"->"vi"->shell sequence). It was beginning to look like "more" had features that, in the given application, were security holes (and weren't easily pluggable). A simpler tool (like "p" or a browser) would probably be less likely to have those holes. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
stevel@haddock.UUCP (02/16/85)
Why does he leave the subprogram in super user mode?
robert@gitpyr.UUCP (Robert Viduya) (02/17/85)
>< Posted from vip@philabs.UUCP > >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. > > Okay, Guy, great. But what if you want your users to use a program like > vi? Then what? I would like users to be able to use an editor. Vi and > most other editors, with the exception of some of the third-party > (expensive) stuff, allow the user to escape to a shell. > System V has an editor called red(1) which is just a restricted version of ed(1). The restrictions are that you can only edit files in the current directory and the '!' shell escape command is disallowed. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
dmcanzi@watdcsu.UUCP (David Canzi) (02/19/85)
>> >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. ... >> >> But what if you want your users to use a program like >> vi? Then what? I would like users to be able to use an editor. Vi and >> most other editors, with the exception of some of the third-party >> (expensive) stuff, allow the user to escape to a shell. > >System V has an editor called red(1) which is just a restricted version of >ed(1). The restrictions are that you can only edit files in the current >directory and the '!' shell escape command is disallowed. The solution to the *real* problem, that of preventing the user from getting unrestricted use of too much privilege has already been posted -- fork, then setuid to the user's own userid, then exec to more. This way the user can do what he bloody well pleases, safely. I worked as a systems programmer on CMS, for the very same organization for which I am still working, and was much disenchanted with a local abomination called "student CMS". Student CMS is a "padded cell environment", in which the user is deprived of most of the facilities available to regular CMS users. Internally, almost every useful facility implemented in CMS has to have ugly kluges inserted to check whether it is being used from student CMS and not to work, or to work differently if so. A great deal of effort has gone into implementing student CMS, and much effort must be spent on maintaining it. Bluntly, much potentially productive effort has been used, instead, to reduce the capabilities of the system. I consider this a perversion of the natural order of things. The facilities provided by the Unix kernel for keeping Joe Random User out of places where he doesn't belong are sufficient. Use *them*, instead of building padded cells, okay? I do not approve of red(1), now that I know it exists. -- David Canzi