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