From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 17:48:32 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E984E905; Thu, 3 Jan 2013 17:48:31 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id BAEE37BE; Thu, 3 Jan 2013 17:48:31 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r03HmTrH003893; Thu, 3 Jan 2013 10:48:29 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <50E5C468.7080700@FreeBSD.org> Date: Thu, 03 Jan 2013 10:48:24 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: FreeBSD-Jail , freebsd-net@FreeBSD.org Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket References: <50E4F7A9.4070900@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Thiel , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:48:32 -0000 On 01/03/13 02:36, Bjoern A. Zeeb wrote: > On Wed, 2 Jan 2013, Jamie Gritton wrote: > >> I've been looking at PR kern/169751, which was noting that routing >> sockets don't work inside a jail. It made the point that setting >> security.jail.socket_unixiproute_only or >> security.jail.allow_raw_sockets didn't help things. It would seem kind >> of a given from the "unixiproute" name that a route socket ought to >> work. And indeed, such a socket is permitted to be created in such a >> jail. It's just using it that doesn't work. >> >> I narrowed this failure down to line 816 of sys/net/rtsock.c, which >> explicitly denies jails from reading routes, regardless of the setting >> of the above two sysctls (or the jail allow.* bits they work with). >> And that bit of code came about in response to PR kern/68189, which >> noted that jails could see interfaces that aren't theirs (i.e. their >> address doesn't live on it). >> >> So we have two PRs that are kind of at cross purposes. It would be >> nice to keep hiding non-jail interfaces from a jail, but it would also >> be nice to let > > jails have no notion of interfaces, only addresses, so by defintiion > there cannot be "non-jail interfaces". Technically yes. But jails do have IP addresses that are tied to interfaces. Still, there's too much of a morass that direction. >> a jailed process know the route to somewhere - at least sometimes. One >> solution would be to add a much finer layer of control to the jail >> test in rtsock.c, looking at interfaces and seeing if they're somehow >> connected with one of the jail's IP addresses. But that just seems >> like a lot of messy corner-case code. >> >> Another way around this, and what I'd like to go with if there are no >> objections, is to allow the route sockets to be used by jails that >> have raw_sockets permission. I know that's kind of a semantic leap, >> but it seems that a jail that has the power of using raw sockets would >> be able to do pretty much as it pleases with routes anyway if it tried >> hard enough. Also, it would be consistent to allow such operations on >> jails that aren't IP-restricted, or in VIMAGE jails. > > I have not further looked at the code but the answer is that we should > not further complicate jails after 14 years when we have a perfect > good solution for the problem; vnets are there for exactly this. > Someone with enough interest and time should just finish things (tm) ;-) I would at least want to open all network things up to jails that have no network restrictions, because they aren't really "jails in the network sense." > Meanwhile your suggestion might be ok given simple enough, but I wonder > if a different flag would be helpful still. I would not be able to > "trust" (the little that is possible anyway) raw_sockets anymore if they > suddently could fiddle with the routing table - even read-only, should > that really be enough. > I would explicitly advertise it as 'do not use - will go away again' > feature and it should the moment vnets are declared non-experimental. > > Just my 2cts. > > /bz Well I'd rather not introduce something as a stopgap. Either this is worth doing or it isn't. It does make sense to at least make sure it works with VNET. - Jamie