Date: Thu, 18 May 2000 10:47:03 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Geoffrey Robinson <geoff@grobin.org> Cc: security@freebsd.org Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? Message-ID: <Pine.NEB.3.96L.1000518104233.25211F-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.10.10005171842470.81906-100000@grobin.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 May 2000, Geoffrey Robinson wrote: > On Wed, 17 May 2000, Robert Watson wrote: > > > Jail works by: > > > > 1) Chrooting the child process > > 2) Limiting the scope of superuser privileges accessible by uid0 processes > > in the jail > > > > It does not attempt to prevent processes outside the jail from > > communicating with processes within the jail. As such, having a process > > do so wouldn't defeat the jail per se, but would defeat the purpose of the > > jail :-). > > Still, like any network service the security impact would depend on how > well the server application was written not on the fact you have a link to > the host system. Right? The point of jail() is to limit the scope of compromise, if any, to within the jail. As such, the integrity of a jail should rest with the applications that run in it, but the integrity of the host should not. I.e., one of the intended environments for jail use is a delegation model wherein virtual subsystems are provided to individuals/groups/organizations for their own management. By virtue of the jail'd file system being a subset of the host file system, communication is possible between jails and the host (as well as signal delivery, et al), but any such communication should have to be initiated by processes outside the jail, not from within. > > One way to substantially improve jail scalability would be to allow the > > same (read-only) file system to be present in all jails as the root, with > > only jail-local data being modified. You can imagine gratuitously using > > nullfs (if it worked) to do this, and mount per-jail writable fs's for > > appropriatel subdirectories (/etc, /usr/local, /home) with appropriate > > symlinks within the jail. Right now, each jail costs you the size of > > world, and is hard to upgrade if you have any decent number of jails. > > Storing all that stuff in a single tree mapped read-only into jails would > > solve that (you'd probably want two so you could upgrade one, test it, and > > then swap to that for all jails so as to minimize downtime). > > If I wanted to do that. Would it be as easy as building a jail on a > spare partition then mounting it read-only to the correct locations? Right now the device handling prevents multiple read-only mounts of the same partition in multiple places. This is unfortunate, but I understand that Poul-Henning Kemp's changes to the bio/device management will address this, among other things. That said, it would be more efficient to make use of some sort of name space translation (assuming our VFS could do it) as you could allow greater reuse of storage/management resources. I assume the buffer cache would be shared between the two in the multi-mount case, but not the vnodes. That might also be the case in the namespace translation instance, so it may be lose-lose in both situations. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000518104233.25211F-100000>