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

[Jamie Gritton]

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

- Jamie