Date: Tue, 16 May 2000 13:05:04 -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.1000516125854.15891D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.10.10005151143580.75260-100000@grobin.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 May 2000, Geoffrey Robinson wrote: > > ver: FreeBSD 4.0-STABLE #0: Sun May 14 11:06:58 EDT 2000 > > I'm planning to use jail in the near future to do two things. First is > to generally increase the security of a system by putting services like > http, smtp, ftp, etc. into separate jails to decrease the potential harm > of a security hole. This system will only allow shell accesses to > trusted individuals. The second plan is to create multiple, virtual > servers on another host system. These virtual servers will allow shell > access to semi-trusted individuals, including the jail root user. Also > the jail administrator could potentially run unsecure services. This > second plan is tentative depending on the reliability of jail. > > I have setup a test jail on my workstation with good results. The first > problem I have found is that I can't access the jailed IP at all from > the host system, nor the host system from the jailed one. However both > host and jailed IPs are accessible to other machines on the network. Is > this intentional? The jailed system can access the Internet fine through > my natd setup on the host system (which actually surprised me). I'm It sounds like a configuration error. Jail merely limits the scope of bindable addresses; it shouldn't limit connectivity between them unless that limit existed without the jail present. Check that you're aliasing the IPs properly -- specifically, that you're adding IP aliases with a netmask of 255.255.255.255. > 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. :-) > Finally how secure is jail really? I'm aware of a trivial chroot breakout > technique. Does that hole still exist? Are there any other known holes? Is > jail still under active development? Is it worth the trouble to do any of > this? 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. 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. Right now my efforts are primarily aimed at improving the security abstractions within the kernel relating to the TrustedBSD project--this should have a side benefit of improving the relationship between jail() and the base OS, making Jail easier to maintain and modify. 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.1000516125854.15891D-100000>