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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
