From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 09:36:09 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6AC72BF; Thu, 3 Jan 2013 09:36:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 790F3A03; Thu, 3 Jan 2013 09:36:09 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CCF8C25D39FD; Thu, 3 Jan 2013 09:36:07 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E28D9BE849B; Thu, 3 Jan 2013 09:36:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id UyQXKKm90s5O; Thu, 3 Jan 2013 09:36:05 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E67B2BE846B; Thu, 3 Jan 2013 09:36:01 +0000 (UTC) Date: Thu, 3 Jan 2013 09:36:01 +0000 (UTC) From: "Bjoern A. Zeeb" To: Jamie Gritton Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket In-Reply-To: <50E4F7A9.4070900@FreeBSD.org> Message-ID: References: <50E4F7A9.4070900@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 09:36:10 -0000 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". > 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) ;-) 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 -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.