Date: Thu, 3 Jan 2013 09:36:01 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Jamie Gritton <jamie@FreeBSD.org> Cc: David Thiel <lx@redundancy.redundancy.org>, freebsd-net@FreeBSD.org, FreeBSD-Jail <freebsd-jail@FreeBSD.org> Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket Message-ID: <alpine.BSF.2.00.1301030926030.4401@ai.fobar.qr> In-Reply-To: <50E4F7A9.4070900@FreeBSD.org> References: <50E4F7A9.4070900@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1301030926030.4401>