Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket
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, 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 -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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
Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket
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
Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket
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-jail@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-jail To unsubscribe, send any mail to freebsd-jail-unsubscr...@freebsd.org
Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket
On Thu, Jan 03, 2013 at 10:48:24AM -0700, Jamie Gritton wrote: On 01/03/13 02:36, Bjoern A. Zeeb wrote: 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. 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. Hello all, Thanks for your consideration of the issue. I don't think it would necessarily have to be a stopgap - I think something like jail.socket_allow_readroute, default 0, wouldn't hurt anything and would definitely help some folks, as this issue has arisen for multiple people over the years. While I agree that vnets will be a great future solution, I think that the very existence of unixiproute_only is kind of problematic, as it implies that jails should be able to use routing sockets by default (read-only, presumably). If we don't want to allow that, should it at least be slated to rename/redocument this sysctl at some point in the future? Or is it intended that VNET totally replace old jail infrastructure, obviating the need for that sysctl at all? -David ___ 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
kern/68189 and kern/169751: what jails are allowed to see in a routing socket
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 ___ 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
