From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 17:52:08 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 2408FC16; Thu, 3 Jan 2013 17:52:08 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs139.luxsci.com (rs139.luxsci.com [72.32.23.91]) by mx1.freebsd.org (Postfix) with ESMTP id DFEC8801; Thu, 3 Jan 2013 17:52:07 +0000 (UTC) Received: from rs139.luxsci.com (localhost.localdomain [127.0.0.1]) by rs139.luxsci.com (8.13.8/8.13.8) with ESMTP id r03Hk6fR030241; Thu, 3 Jan 2013 11:46:07 -0600 Received: (from root@localhost) by rs139.luxsci.com (8.13.8/8.13.8/Submit) id r03Hk5RB030164; Thu, 3 Jan 2013 17:46:05 GMT Received: (from sender 74627) (rs139.luxsci.com [127.0.0.1]) by LuxSci SP; Thu, 03 Jan 2013 17:46:02 +0000 Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket Content-Type: text/plain; charset=us-ascii From: "Isaac (.ike) Levy" In-Reply-To: Date: Thu, 3 Jan 2013 12:45:41 -0500 Content-Transfer-Encoding: quoted-printable References: <50E4F7A9.4070900@FreeBSD.org> To: "Bjoern A. Zeeb" , Jamie Gritton X-Lux-Comment: Message r03HjfLa029309 sent by user #74627 Message-Id: <1357235165-2012934.06566733.fr03HjfLa029309@rs139.luxsci.com> X-Comment: LuxSci SP Message ID - 1357235165-2012934.06566733 Cc: David Thiel , freebsd-net@freebsd.org, FreeBSD-Jail 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:52:08 -0000 Hi Jamie, All, On Jan 3, 2013, at 4:36 AM, Bjoern A. Zeeb wrote: > On Wed, 2 Jan 2013, Jamie Gritton wrote: >=20 >> 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. >>=20 >> 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). >>=20 >> 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 >=20 > jails have no notion of interfaces, only addresses, so by defintiion > there cannot be "non-jail interfaces". >=20 >=20 >> 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. >>=20 >> Another way around this, and what I'd like to go with if there are no = objections, I humbly object. >> 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. >=20 > 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) = ;-) >=20 > 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. >=20 > Just my 2cts. >=20 > /bz I'm going to enthusiastically agree with Bjoern here, especially when = vnets exist. I see your point, and your need, but this kind of virtual server centric = approach is better applied, full-bore, to other server virtualization = models, where interfaces actually exist, (in the form of abstracted = hardware). I believe allowing this sort of abstraction is precisely the kind of = fundamentals-bending which has led other virtual server implementations = to the bone pile- jail(2) is securable and useful explicitly because it = is fundamentally designed to contain resources, not emulate them. Best, .ike