Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekfdi!videovax!bart
From: bart@videovax.tv.tek.com (Bart Massey)
Newsgroups: comp.sources.d
Subject: Re: Safer unsharing
Message-ID: <5598@videovax.tv.tek.com>
Date: 18 Oct 89 00:26:43 GMT
References: <15018@bloom-beacon.MIT.EDU> <1989Oct15.010101.27015@NCoast.ORG> <768@vector.Dallas.TX.US>
Reply-To: bart@videovax.tv.tek.com (Bart Massey)
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 22

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