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