Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ncoast.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!dual!amd!decwrl!decvax!cwruecmp!atvax!ncoast!bsafw From: bsafw@ncoast.UUCP (The WITNESS) Newsgroups: net.unix-wizards Subject: Re: Is the restricted shell really secure? Message-ID: <210@ncoast.UUCP> Date: Mon, 30-Jul-84 11:28:38 EDT Article-I.D.: ncoast.210 Posted: Mon Jul 30 11:28:38 1984 Date-Received: Sat, 4-Aug-84 01:30:08 EDT References: <275@pcsbst.UUCP> <990@inuxc.UUCP> <280@genrad.UUCP> Organization: North Coast XENIX, Cleveland Lines: 24 On a related question: we have implemented a restricted filesystem-cum-shell by means of a program that does a Xenix chroot() syscall and then execs the shell. But the only way to make it really secure, that I can see, is to break the '..' link in the restricted root. Anyone see a way that won't get fsck upset? For those (a majority, I would guess) without chroot system call: it causes the current process to consider / to point to the directory named in the call. The program that we use does this: main() { chroot("/ROOT"); chdir("/usr/guest"); /* actually /ROOT/usr/guest */ setuid(GUESTUID); setgid(GUESTGID); execl("/bin/tsh", "tsh", 0); } Thanks for any help you can provide. -- Brandon Allbery: decvax!cwruecmp{!atvax}!bsafw 6504 Chestnut Road, Independence, OH 44131 Witness, n. To watch and learn, joyously.