drw@math.mit.edu (Dale R. Worley) (10/11/89)
I may be naieve, but I would think that between running sh from a non-root account, and use of chroot(), one would be able to confine the damage from a dangerous archive to just one part of the directory tree. Why doesn't this work? Dale drw@math.mit.edu
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/12/89)
In <15018@bloom-beacon.MIT.EDU>, drw@math.mit.edu (Dale R. Worley) writes: | [ run /bin/sh under chroot or as limited user ] | | Why doesn't this work? It does. The complaint is that you need to be root to run the chroot. Also, the environment has to be complete enough to include all of the things which a shar might reasonably use, like cat, sed, sum, col, test (and [), etc. The other alternative you mention, a userid just for unshar, is much easier. I created such an id on my system, and a little program to do the su to it and execute the script. It then scans for files and directories which are (a) setuid, (b) not owned by the special user, or (c) executable and world or group write. Either of these are a pain to set up and use. If there were a better way to pass files around shar would have died long ago. Since everyone has /bin/sh the true shar format is very convenient. For SysV users a SysV /bin/sh (that's a lot of us these days) a directory may be created which holds a few common commands, then the restricted shell with a limited path may be run, something like: PATH=/limitedbin; readonly PATH set -r . sharfile I make no claim that this is perfect, just quick and easy to use, and a lot better than nothing. A quick scan through the shar for filenames with leading / is advised, too. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
allbery@NCoast.ORG (Brandon S. Allbery) (10/15/89)
As quoted from <15018@bloom-beacon.MIT.EDU> by drw@math.mit.edu (Dale R. Worley): +--------------- | I may be naieve, but I would think that between running sh from a | non-root account, and use of chroot(), one would be able to confine | the damage from a dangerous archive to just one part of the directory | tree. Why doesn't this work? +--------------- It *does* work. But assembling a *usable* chroot area is non-trivial: you need to construct copies of /bin, /usr/bin, /etc (for chown/chgrp on Berzerk systems), /usr/ucb (ditto), etc. in your chroot area, and to be absolutely safe they should be copies, not links, of the originals. This wastes space and takes more than a little time, and if you forget to include some utility in /bin you have to go put it in and re-unshar. Add that chroot() requires root permissions. Summary: It works fine if you can swing it, but it's too much of a chore. It's likely to be easier to keep a spare machine around to do your unshar's on. (You always knew there was a reason for System V/286. ;-) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
allbery@NCoast.ORG (Brandon S. Allbery) (10/15/89)
As quoted from <1008@crdos1.crd.ge.COM> by davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr): +--------------- | Either of these are a pain to set up and use. If there were a better | way to pass files around shar would have died long ago. Since everyone | has /bin/sh the true shar format is very convenient. +--------------- How about a GNU version of ar, expanded to include directories? Both System V and Berzerkeley use ASCII ar format now, and the two differ by exactly *one* character per archive entry (BSD uses a space, USG uses a `). +--------------- | For SysV users a SysV /bin/sh (that's a lot of us these days) a | directory may be created which holds a few common commands, then the | restricted shell with a limited path may be run, something like: | PATH=/limitedbin; readonly PATH | set -r | . sharfile +--------------- ...which will fail the first time you run one of those shars whose first executable line is "PATH=/bin:/usr/bin:/usr/ucb export PATH".... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
chip@vector.Dallas.TX.US (Chip Rosenthal) (10/16/89)
allbery@ncoast.ORG (Brandon S. Allbery) writes: >quoted from <15018@bloom-beacon.MIT.EDU> by drw@math.mit.edu (Dale R. Worley): >+--------------- >| I would think that between running sh from a non-root account, and use of >| chroot(), one would be able to confine the damage from a dangerous archive >+--------------- >It *does* work. But assembling a *usable* chroot area is non-trivial Under XENIX (and correspondingly SysVish looking things), I've found the following structure to work most of the time: /usr/spool/unshar: bin/ dev/ tmp/ /usr/spool/unshar/bin: awk* cat* chmod* cp* mkdir* rm* sed* sh* wc* /usr/spool/unshar/dev: null tty /usr/spool/unshar/tmp: where I do a chroot("/usr/spool/unshar") and unpack into the (relative) /tmp. By far, the biggest problem is the archives which insist upon an unpacking order, not missing executables. The next (and a distant next) most frequent complaint is about missing "chown" and "chgrp". This is intentional. No %*#(@ shar archive should have this sort of command in it. Stamp out complex shar archives. Small is beeyooteefull. -- Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337 Someday the whole country will be one vast "Metroplex" - Zippy's friend Griffy
bart@videovax.tv.tek.com (Bart Massey) (10/18/89)
In article <768@vector.Dallas.TX.US> chip@vector.Dallas.TX.US (Chip Rosenthal) writes: > Under XENIX (and correspondingly SysVish looking things), I've found the > following structure to work most of the time: ... > /usr/spool/unshar/dev: > null tty ... > where I do a chroot("/usr/spool/unshar") and unpack into the (relative) /tmp. Note that if you include /dev/tty on BSD systems, at least, there's an obscure security hole involving use of the "simulate terminal input" ioctl. Workarounds: make an account which does the chroot and *log into it* to unshar things, disable TIOCSTI in your kernel (it's more of a security hole than a feature in most cases anyhow...). On the other hand, who cares -- I've never worried much about trojan-horse shars, since it's a gob easier to trojan-horse the program contained in the shar anyhow, and I almost never unshar bits I don't want to execute :-). Bart Massey ..tektronix!videovax.tv.tek.com!bart ..tektronix!reed.bitnet!bart