<div dir="ltr">Kevin,<div><br></div><div>On 8 June 2015 at 23:52, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>There is a bug in security groups here: <a href="https://bugs.launchpad.net/neutron/+bug/1359523" target="_blank">https://bugs.launchpad.net/neutron/+bug/1359523</a></div><div><br></div><div>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:</div><div><br></div><div>create two networks with same <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a></div><div>create port1 in SG1 on net1 with IP 10.0.0.1<br></div><div>create port2 in SG1 on net2 with IP 10.0.0.2</div><div>create port3 in SG2 on net1 with IP 10.0.0.2</div><div>create port4 in SG2 on net2 with IP 10.0.0.1</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>port1 can communicate with port3 because of the allow rule for port2's IP</div><div>port2 can communicate with port4 because of the allow rule for port1's IP</div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>The scenario you're describing is quite concerning from a security perspective. Shouldn't there be L2 isolation to prevent something like this?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>The paragraph above is a bit obscure to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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 <a href="http://0.0.0.0/0">0.0.0.0/0</a> (for v4).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Implement address scopes.</div></div></blockquote><div><br></div><div>Sure, my master. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>Cheers!</div><span class=""><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>