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.