carey@m.cs.uiuc.edu (12/19/89)
I have made a guest login on one of our machines, for outside people to get access to some notesfiles and send mail to users and things like that. It runs a shell script (bourne shell), which allows the guest user to choose from a menu of things to do. I want to keep people in this shell script, and not allow them to have access to a regular shell. One thing I have tried to prevent is having people send interrupts and things like that to interrupt the shell script. Another big problem is that many things, like notes, mail, and even editors, have "shell escapes" built into them. Is there any way to prevent people from using these shell escapes, or at least having them not be able to do anything once they have done it? Do I have to rewrite mail and editors, to disable the shell escapes? I wanted to avoid using the "rsh" (restricted shell) since that is kind of an administrative hassle. It would be better than rewriting editors. The best thing would be some kind of trick to have them end up in a black hole somewhere when they do a shell escape.
cliffs@sun.com (Clifford C. Skolnick) (12/20/89)
I'll tell you what I did at a former job. It's ugly, but it worked. What
we did was check argv[0][0] in the shell to see if it was a "-", which will
usually signifies a login shell. If it was not equal, we would check the uid
to see if it matched a list of uid's to not allow interactive shell access.
This did break some things, like runing "grep" and "awk" stuff out of vi. I
also remember rn "follow-up" feature breaking. There were many others, but
this was better than nothing. You can also place this in a wrapper on the
real /bin/sh if you do not have source.
In article <9100020@m.cs.uiuc.edu> carey@m.cs.uiuc.edu writes:
Path: playroom!east!newstop!sun-barr!apple!mips!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!carey
From: carey@m.cs.uiuc.edu
Newsgroups: comp.unix.wizards
Date: 19 Dec 89 01:38:49 GMT
Lines: 21
Nf-ID: #N:m.cs.uiuc.edu:9100020:000:1071
Nf-From: m.cs.uiuc.edu!carey Dec 18 10:42:00 1989
I have made a guest login on one of our machines, for outside people
to get access to some notesfiles and send mail to users and things like
that. It runs a shell script (bourne shell), which allows the guest
user to choose from a menu of things to do.
I want to keep people in this shell script, and not allow them to have
access to a regular shell. One thing I have tried to prevent is having
people send interrupts and things like that to interrupt the shell
script.
Another big problem is that many things, like notes, mail, and even editors,
have "shell escapes" built into them.
Is there any way to prevent people from using these shell escapes, or at least
having them not be able to do anything once they have done it? Do I have to
rewrite mail and editors, to disable the shell escapes? I wanted to avoid
using the "rsh" (restricted shell) since that is kind of an administrative
hassle. It would be better than rewriting editors. The best thing would
be some kind of trick to have them end up in a black hole somewhere when
they do a shell escape.
--
Cliff Skolnick cliffs@sun.com
Sun Microsystems Inc. (I only work for them. I do not speak for them)
"The floggings will continue until morale improves"nik@st_nik.UUCP (Nik Simpson x333) (12/20/89)
I encountered this problem writing some menu based code a couple of years ago, in most case programs that allow a shell escape seem to check the value of the shell variable SHELL, and exec this as the shell. If you change SHELL either using putenv if you are working in executable or SHELL="something harmless";export SHELL In a script this disbles shell escapes from most well behaved programs in my experience. -- |--------------------------------------------------| | Nik Simpson UUCP : uunet!ingr!swndn!st_nik!nik| | Senior Systems Engineer. Intergraph UK Ltd. | |--------------------------------------------------|
tcurrey@x102c.harris-atd.com (currey tom 76327) (12/20/89)
I was playing with the same type of idea. I think a login shell that performed a "chroot" function like anonymous ftp, would take care of any accessing problems outside the desired area. I have not worked on it enough to make this function. This is just a suggestion. If anyone already has such a program, I would like to see it if possible Tom Currey tcurrey@x102c.harris-atd.com
martin@mwtech.UUCP (Martin Weitzel) (12/20/89)
In article <9100020@m.cs.uiuc.edu> carey@m.cs.uiuc.edu writes: > >I have made a guest login on one of our machines, for outside people >to get access to some notesfiles and send mail to users and things like >that. It runs a shell script (bourne shell), which allows the guest >user to choose from a menu of things to do. > >I want to keep people in this shell script, and not allow them to have >access to a regular shell. One thing I have tried to prevent is having >people send interrupts and things like that to interrupt the shell >script. > You should *very* strongly consider, to let those unprotected guest logins run in a 'chroot'-ed environment. There were some recent postings, explaining how this could be done without any programming, if you place a '*' in the 'shell'-field of "/etc/passwd". (I did not try it, but if it shouldn't work, it's not so hard to do what is necessary by a small program you write yourself.) Chroot is not so well documented in the most systems. Basically it changes the 'root'-directory for a process and all its children. This effectivly limits the accessible part of the file system to a subtree of your choice - the subtree below the new root. It requires a little bit of thinking, which commands should be placed into the 'chroot'-ed environment, because clearly the "/bin", "/usr/bin" -Directories would no longer be accessible, from a new root, say "/usr/guestroot". But this thinking is worth the effort, because then you can be sure of the worst case that may happen, if you have overlooked a possibility, how someone might get an interactive shell. My prefered technique would be to place the new root on a separate disk partition, because then an evil 'guest' would not have the possibility to fill my other file systems. >Another big problem is that many things, like notes, mail, and even editors, >have "shell escapes" built into them. > >Is there any way to prevent people from using these shell escapes, or at least >having them not be able to do anything once they have done it? Do I have to >rewrite mail and editors, to disable the shell escapes? I wanted to avoid >using the "rsh" (restricted shell) since that is kind of an administrative Professionell software should obbey some environment variable (often it is named SHELL) to decide, if a "shell escape" is allowed. But please, do not depend on this or worse, rely on it: If you don't have the source of the program, you can never decide if there are some 'hidden' ways, the programmer has overlooked. (There is many poor software out, that was not at all programmed with security in mind. For obvious reasons, I'll not give any examples here.) If you yourself are a programming, you should read the book: "UNIX System Security", by Kochan & Wood, which explains the possible pitfalls in detail. >hassle. It would be better than rewriting editors. The best thing would >be some kind of trick to have them end up in a black hole somewhere when >they do a shell escape. If you use the 'chroot' approach, that I described above, it should be easy to replace the shell by some 'black hole', if none of the software that is used there, depends on "/bin/sh" beeing the 'real bourne shell' - because "/bin/sh" is the file "sh" in the directory "bin" below your *new* root! -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
foessmei@lan.informatik.tu-muenchen.dbp.de (Reinhard Foessmeier) (12/22/89)
In article <1078@st_nik.UUCP> nik@st_nik.UUCP (Nik Simpson x333) writes:
-> ... If
->you change SHELL either using putenv if you are working in executable
->or
-> SHELL="something harmless";export SHELL
->
-> In a script this disbles shell escapes from most well behaved programs
->in my experience.
->--
Mi ne scias, chu vi nomus "vi" I don't know if you call "vi" a well
bonkonduta programo. Sed "vi" behaved program. Yet "vi" allows you
permesas al vi shanghi la valoron to change the value of "SHELL" by
de "SHELL", per la ordono typing the command
":set shell=/bin/sh". Do gardu vin! ":set shell=/bin/sh". So beware!
Reinhard F"o"smeier
-----
Reinhard F\"ossmeier, Technische Univ. M\"unchen | UNOX is a trademark of
foessmeier@infovax.informatik.tu-muenchen.dbp.de | "Union Deutsche
[ { relay.cs.net | unido.uucp } ] | Lebensmittelwerke GmbH"exspes@gdr.bath.ac.uk (P E Smee) (12/22/89)
In article <562@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >You should *very* strongly consider, to let those unprotected guest >logins run in a 'chroot'-ed environment. There were some recent >postings, explaining how this could be done without any programming, >if you place a '*' in the 'shell'-field of "/etc/passwd". (I did not Can any kind soul mail me a copy of the postings to which Martin refers? I missed them, the topic is relevant to a server we are trying to build on a Sun 'server' (console-less workstation), and they have aged out and vanished at Bath. -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
larry@macom1.UUCP (Larry Taborek) (12/22/89)
From article <9100020@m.cs.uiuc.edu>, by carey@m.cs.uiuc.edu: > > I want to keep people in this shell script, and not allow them to have > access to a regular shell. One thing I have tried to prevent is having > people send interrupts and things like that to interrupt the shell > script. > > Another big problem is that many things, like notes, mail, and even editors, > have "shell escapes" built into them. > > Is there any way to prevent people from using these shell escapes, or at least > having them not be able to do anything once they have done it? Do I have to > rewrite mail and editors, to disable the shell escapes? I wanted to avoid > using the "rsh" (restricted shell) since that is kind of an administrative > hassle. It would be better than rewriting editors. The best thing would > be some kind of trick to have them end up in a black hole somewhere when > they do a shell escape. Well, one thing I noticed in reading the login source for 5.2 is that if you have a "*" character in the shell field of an account in the password file, then login will do a change root to that accounts home directory field and attempt to respin a local login. Once root has been changed to that subdirectory (now called localroot), then underneith localroot you will need a bin, etc and dev directory. Naturally you will need a login program in either localroot/etc or localroot/bin. a /localroot/etc/passwd file is also necessary. Now if you don't have a sh or csh or ksh program available in localroot/bin, then I don't believe that they can -ever- access the shell, as for them there is no shell to access. And if they did, where would they go... :-) By the way, NEAT feature guys... -- Larry Taborek ..!uunet!grebyn!macom1!larry Centel Federal Systems larry@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 My views do not reflect those of Centel 703-758-7000
merlyn@iwarp.intel.com (Randal Schwartz) (12/23/89)
In article <1078@st_nik.UUCP>, nik@st_nik (Nik Simpson x333) writes: | | I encountered this problem writing some menu based code a couple of | years ago, in most case programs that allow a shell escape seem to check | the value of the shell variable SHELL, and exec this as the shell. If | you change SHELL either using putenv if you are working in executable | or | SHELL="something harmless";export SHELL | | In a script this disbles shell escapes from most well behaved programs | in my experience. Except in 'vi'. You can ":set shell=/bin/sh" any'ol' time. As has been said before, you need a completely separate environment to get complete security, and this is no exception. Just another security weenie, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
ske@pkmab.se (Kristoffer Eriksson) (12/23/89)
In article <562@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >You should *very* strongly consider, to let those unprotected guest >logins run in a 'chroot'-ed environment. Is there any way to allow a "chroot-ed" user to exchange mail and news with the rest of the system? I've tried to come up with a simple solution, but failed. The problem is that the spool directories for mail and news are not accessible from inside the "chroot-ed" environment. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (12/28/89)
In article <2481@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes:
: Is there any way to allow a "chroot-ed" user to exchange mail and news
: with the rest of the system? I've tried to come up with a simple solution,
: but failed. The problem is that the spool directories for mail and news
: are not accessible from inside the "chroot-ed" environment.
It's socket to me time!
I don't know if this counts as a simple solution, but presuming you have
sockets, you can use SMTP and NNTP to yourself. With NNTP you can likely
read news transparently. To use SMTP, though, you'd probably have to pretend
you were another machine to get it to forward your mail. But you can send
mail with telnet.
But you might be able to read your mail directly with FTP, depending on
how /etc/shells is set up. Of course, if you can do that, there's little
point in the chroot in the first place...
Larry Wall
lwall@jpl-devvax.jpl.nasa.govlarry@macom1.UUCP (Larry Taborek) (12/28/89)
From article <2481@pkmab.se>, by ske@pkmab.se (Kristoffer Eriksson): > Is there any way to allow a "chroot-ed" user to exchange mail and news > with the rest of the system? I've tried to come up with a simple solution, > but failed. The problem is that the spool directories for mail and news > are not accessible from inside the "chroot-ed" environment. Try this... So your chroot-ed (localroot) area has its own spool/mail area where mail is delivered. Make a account on the localroot password file called "up". Next post a message to up, and in the subject line put in the mailbox address of the person that you want it delivered to. Now write a daemon using sh that is run from the main root area (so it can look at all the localroot areas) and have it peek every few minutes into the mail area of localroot to see if "up" exists, and "up.lock" does not. If so, copy the "up" file into /usr/tmp and run a text process program that will bust up the mail gram into sub mail gram files, addressed to the old Subject line. Now remail those sub mail gram files. Its kludgy, I know, but it should work.... Hope this helps... -- Larry Taborek ..!uunet!grebyn!macom1!larry Centel Federal Systems larry@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 My views do not reflect those of Centel 703-758-7000