Date: Wed, 17 May 2000 11:05:07 -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.1000516170812.15891F-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.10.10005161420040.77736-100000@grobin.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 May 2000, Geoffrey Robinson wrote: > On Tue, 16 May 2000, Robert Watson wrote: > > > On Mon, 15 May 2000, Geoffrey Robinson wrote: > > > > > ver: FreeBSD 4.0-STABLE #0: Sun May 14 11:06:58 EDT 2000 > <snip> > > > aware that raw sockets are not allowed to jailed processes but is there > > > a workaround for ping and traceroute? > > > > Currently, no. Due to the way raw sockets work (allowing listening for > > all non-handled IP messages, and allowing direct writing of IP packets), > > it would take a bit of work to get this up and running, although it would > > be feasible. A more promising long-term goal might be to better > > virtualize network services, creating virtual interfaces and binding real > > network resources to virtual interfaces. However, that would be far more > > work. :-) > > If a process running in the host system created a UNIX domain socket or > named pipe within the jail directory tree. Would a process running in the > jail be able to connect to and communicate with the host process through > this socket or pipe? If so I guess you could create work around for just > about anything by running it on the host system. Would this create a > potential way of defeating the jail? 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 :-). > > > As far as I know, none of the chroot() breakout mechanisms will work from > > jail(), as long as the jail() file system is constructed and maintained in > > a safe manner. For example, jail() prevents new device nodes from being > > introduced with mknod(). However, this assumes that (a) no improper > > device nodes existed in the accessible file space in the first place, and > > (b) root outside of jail() won't create them in the file space. > > What about upgrading procedures? After my last cvsup and make world > on the host system the jail could be started but could not access the > network. I had to build a new jail from scratch to get it working properly. I'm not clear on why that would happen -- the libc (etc, etc) in each jail should be kept in synch with the kernel, however, and that could be source of your problems. I.e., if you upgrade the kernel, it exports the same syscall interface to all processes, regardless of jails, so all jails making use of syscalls that have changed need to be upgraded in synch. This is the same as upgrading the kernel without upgrading your normal world. 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). > > Jail is being actively maintained; I have some ideas for it in the long > > term, but probably won't get to carrying them to fruition for a few > > months. This includes improved management capability (unique jailids, > > ability to deliver a signal to an entire jail from outside the jail, as > > well as special purpose binaries such as a jailinit to manage setup and > > shutdown of jails in an orderly manner. If you are interested in working > > on such features, I'd be glad to share design thoughts with you, as it > > will take me a while to get to this stuff. > > I would like to try. I don't know how much help I could be. Please, let me > know what I can do. I'll do what I can. I'll gather up my notes on possible improvements and post them to -security sometime in the next week or two. Thanks! 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.1000516170812.15891F-100000>