Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 8/1/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hpda!fortune!amd!decwrl!decvax!harpo!utah-cs!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Is the restricted shell really secure? Message-ID: <41@rlgvax.UUCP> Date: Mon, 6-Aug-84 22:46:37 EDT Article-I.D.: rlgvax.41 Posted: Mon Aug 6 22:46:37 1984 Date-Received: Thu, 9-Aug-84 03:34:12 EDT References: <275@pcsbst.UUCP> <990@inuxc.UUCP> <280@genrad.UUCP> <210@ncoast.UUCP> Organization: CCI Office Systems Group, Reston, VA 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? Yup. Modify "namei" so that if it detects a directory entry called ".." which points above the current root directory, it gets remapped to the current root directory. That's what all 4.xBSD and System X UNIXes do (note; this may give ".." a special meaning, but vanilla V7 also treats some directory entries specially; any entry ".." that moves above the root of a mounted file system gets remapped to the parent of the mount point, to permit 'chdir("..")' to work correctly from a mount point). > 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. If it is the majority, that's unfortunate; the system call is provided in V7 and all its successors. The only reason for ripping it out of a UNIX version is fear of the security hole produced by permitting 'chdir("..")' above the fake root, and that's easy to fix. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy