Open Stack

On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton <blak111 at gmail.com> 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

This sounds like a different bug than 1359523. It isn't what was described
in the bug report and has a different underlying cause. While it looks
similar on the surface, could we open up a new bug to track this?  Just
curious has anyone hit this in the wild or is this totally contrived?

My first reaction to this is that if you set this up like this, you deserve
it.  Maybe we just advise that people plan to avoid scenarios that
intersect multiple security groups across disparate L2 networks using
overlapping IP address space.  Don't use overlapping subnets.  Or, if you
do, don't use the same security group across them.  But, that is just a cop
out if we haven't had a discussion.

Using address scopes will prevent any overlap and fix this situation in the
following way.  I think this is what Kevin had in mind:

create two networks with same 10.0.0.0/24 allocating the subnets from an
address pool.  They must be allocated from different subnet scopes.  We
know because if they were the same scope, overlap wouldn't be allowed.  A
fundamental design feature of address scopes is that address overlap is
prevented within the scope.

  Net1 has address scope a and net2 has address scope b.   All the subnets
on a network from the same address family are required to be from the same
pool.  Hence, they'll be in the same scope.

  create port1 in SG1 on net1 with IP 10.0.0.1.  Has address scope a
  create port2 in SG1 on net2 with IP 10.0.0.2.  Has address scope b
  create port3 in SG2 on net1 with IP 10.0.0.2.  Has address scope a
  create port4 in SG2 on net2 with IP 10.0.0.1.  Has address scope b

The scope names are arbitrary and contrived but we know that port1 and
port3 must be in the same scope because they are on the same network.  We
also know that a != b because the same scope wouldn't allow the overlap.

> 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

These would be prevented if the security group code notices that port1 and
port2 are not in the same scope and therefore will never be able to
communicate without some sort of NAT in between.  It should leave out the
allow rules because of this.

Same for port3 and port4 in the other SG.

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

I said the same thing just with a little more specificity and referring to
the example.

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

I'm not inclined to invest a lot of effort in to this.  I don't see it as a
big security hole.  Is there a way to exploit this that I cannot see?  I'm
still inclined to say that we should come up with some kind of advise for
how to manage SGs and networks to avoid it.

> Implement address scopes.

I will. Stay tuned.  I did not, however, include any kind of integration
with security groups with my address scopes spec.  I don't think I should
necessarily stop everything to include it either.  I still tend to think
that this example is a bit contrived which is why I've asked if this was
hit in the wild.

You should keep in mind that address scopes will not be forced on anyone.
You will get the same thing as today if you continue to make all the same
API calls to set it up. Address scopes will only come in to play if you use
subnet pools. If you don't use subnet pools, you can still create
overlapping address ranges.  So, we can make security groups address scope
aware but it won't fix the problem for existing models.

Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150609/acdc934a/attachment.html>