Date: Tue, 8 May 2001 23:54:04 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Dave Whitaker <freebsd-security@pozer.org> Cc: freebsd-security@freebsd.org Subject: Re: Jails and FreeBSD4.3 Message-ID: <Pine.NEB.3.96L.1010508233716.11741q-100000@fledge.watson.org> In-Reply-To: <20010507121223.C33043@moo.udder.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 May 2001, Dave Whitaker wrote: > I recently installed FreeBSD 4.3, specifically wanting to mess with > jails. Everything appears to work fine, except I use apache with > mod_vhost_alias, and proftpd hosting several anonymous ftp sites. I > need to get the jail to bind to many IPs, rather than just one. Is > there any way to do this, or would anyone be willing to provide me with > a patch to do so? I've already responded to this to some extent by private e-mail, but since I just caught up with it on the security mailing list, I'll give a quick response here also. Right now, the jail() code in FreeBSD 4.3-STABLE supports binding only a single IP address to a jail. This was by design, as Poul-Henning points out. Due to the way in which jail IP address scoping is performed, there are actually several limitations to removing this restriction, although with some caveats, it can be done with a pretty small patch. The difficulty in removing the limit lies in that jail does not truly polyinstantiate the IP address/port namespace, it merely scopes and modifies the socket calls made by processes in a jail. In particular, it blocks the ability to bind an IP address not associated with the jail, and it performs a conversion of 127.0.0.1 as the target address to the IP associated with the jail. Similarly, if INADDR_ANY is requested as the source address, the jail code forceably selects the jail IP as the source address, instead of using routing information. You'll notice that some applications expecting to use 127.0.0.1 in specific ways will fail as a result of this behavior. When moving to multiple IP addresses on a jail, an additional inconsistency is introduced: the process is not permitted to use INADDR_ANY since there isn't true polyinstantiation, leaving few useful choices for wildcard sockets. In the multiple IP code I'm working with right now, the practical implication is that processes attempting to bind all IPs using INADDR_ANY in fact bind only the first IP. For applications carefully selecting their IP, such as Apache running with virtual domains and specifically bound IPs, this is not a problem. For others, such as inetd, it may mean that only the first IP gets these services. As has been discussed, I'm in the process of implementing a "jailNG" that changes some of the underlying model assumptions of the jail code. These changes are targetted only at 5.0-CURRENT right now, as a primary concern in writing the code has been to migrate to a model that provides compatibility with the SMPng code, and hence support for fine-grained synchronization primitives. Right now, I have no plans to backport the code to the RELENG_4 branch, as it deprecates the existing jail() system call, thus breaking the ABI (which is generally a no-no on a minor release branch). This is because the management model is modifies such that jails are now explicitly created, joined, and destroyed, as they have unique jail "names". This allows jails to be individually managed using the jail.instance.(name).* sysctl namespace, which was an important goal of the new implementation. The existing jail(8) code uses implicit naming, provides no fine-grained management, but does offer automatic garbage collection when the last process in a jail dies. I've posted some initial jailNG patches to http://www.watson.org/~robert/jailng/. I have additional support code going into the tree shortly that permits per-jail securelevels, and once the support code is in the base tree, I'll update jailNG to handle that. I'm of mixed feelings about adding multiple-IP support to the code: it is very much in demand, but further reduces compatibility (broken INADDR_ANY), and introduces a harder optimization problem (scaling to 10,000 IPs per-jail is not as easy as scaling to two). While it is theoretically possible to backport the changes to RELENG_4 (and not very hard at that), and I might even be willing to do that (probably as a for-pay thing since I don't see it as a priority), I think the changes of it making its way into the tree before 5.0-RELEASE are highly unlikely, due to ABI/API changes, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, 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.1010508233716.11741q-100000>