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

[Isaac (.ike) Levy]

Hi Jamie, All,

On Jan 3, 2013, at 4:36 AM, 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".
> 
> 
>> 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,

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.
> 
> 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

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