Kevin, On 8 June 2015 at 23:52, Kevin Benton <[email protected]> wrote:
> There is a bug in security groups here: > https://bugs.launchpad.net/neutron/+bug/1359523 > > In the example scenario, it's caused by conntrack zones not being > isolated. But it also applies to the following scenario that can't be > solved by zones: > > create two networks with same 10.0.0.0/24 > create port1 in SG1 on net1 with IP 10.0.0.1 > create port2 in SG1 on net2 with IP 10.0.0.2 > create port3 in SG2 on net1 with IP 10.0.0.2 > create port4 in SG2 on net2 with IP 10.0.0.1 > > port1 can communicate with port3 because of the allow rule for port2's IP > port2 can communicate with port4 because of the allow rule for port1's IP > So this would be a scenario when bug 1359523 hits even with conntrack zone separation, with the subtle, and terrible difference that there is a way to enable cross-network plugging? For instance to reach port1 on net1, all I have to do is create a network with a CIDR with some overlap with net1's, and then wait until a VM is created with an IP that exists also on net1 - and then jackpot, that VM will basically have access to all of net1's instances? The scenario you're describing is quite concerning from a security perspective. Shouldn't there be L2 isolation to prevent something like this? The solution will require the security groups processing code to understand > that a member of a security group is not actually reachable by another > member and skip the allow rule for that member. > The paragraph above is a bit obscure to me. > > With the current state of things, it will take a tone of kludgy code to > check for routers and router interfaces to see if two IPs can communicate > without NAT. However, if we end up with the concept of address-scopes, it > just becomes a simple address scope comparison. > This is fine, but I wonder how's that related to what you described earlier. Is the vulnerability triggered by the fact that both networks can be attached to the same router? In that case I think that if the l3 mgmt code works as expected it would reject adding an interface for a subnet with an overlap with another already attached subnet, thus implementing an implicit address scope of 0.0.0.0/0 (for v4). > > Implement address scopes. > Sure, my master. > > > Cheers! > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
