[openstack-dev] [neutron] - L3 scope-aware security groups
sorlando at nicira.com
Mon Jun 8 23:07:23 UTC 2015
On 8 June 2015 at 23:52, Kevin Benton <blak111 at gmail.com> wrote:
> There is a bug in security groups here:
> 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
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.
> Kevin Benton
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev