kern/68189 and kern/169751: what jails are allowed to see in a routing socket

[Jamie Gritton]

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