Security Group doesn't work if the specific allowed-address-pairs value is set

Bug #1622657 reported by Danil Akhmetov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Won't Fix
High
Inessa Vasilevskaya
10.0.x
Won't Fix
High
Inessa Vasilevskaya
7.0.x
Won't Fix
High
MOS Maintenance
8.0.x
Won't Fix
High
MOS Maintenance
9.x
Won't Fix
High
Ann Taraday

Bug Description

It's a customer-found issue. The issue is reproducible on MOS 10.0 as well.

Summary:

Security Group doesn't work if the specific allowed-address-pairs value is set to the port associated with it.

High level description:

OpenStack user is allowed to specify arbitrary mac_address/ip_address pairs that are allowed to pass through a port. For some practical reasons, OpenStack users can specify huge subnets, and CIRDs provided there are not sanitized. If the CIRD provided with 'allowed-address-pairs' for any single port associated with Security Group overlaps with a subnet used by the VM, the VM is always accessible by any port and any protocol, despite the fact that its security group denies all ingress traffic.

Step-by-step reproduction process:

1) Create a VM in OpenStack
2) Check that there are no rules allowing icmp (for instance) in the security group associated with the VM
3) perform:
neutron port-update [any-port-associated-with-the-secgroup] --allowed-address-pairs type=dict list=true ip_address=[a-very-huge-cidr]

if your VM uses a private IPv4 address from networks 192.168.x or 172.16.x, then 128.0.0.0/1 will work as "a-very-huge-cidr", if it uses 10.x network then 0.0.0.0/1 should.

4) ping all the VMs in this secgroup successfully (from router namespace, or from any host which is allowed to access floating IPs if floating IP is also assigned to the VM), as well as access it by any port and protocol which the VM is listening.

Version:

All OpenStack releases up to Mitaka.

Perceived severity:

It's not a blocker as workaround are pretty obvious, but it's a huge security bug: all the network security provided by Security Groups might be ruined easily, just by updating a single port in neutron.

If we restrict the value of allowed-address-pairs in neutron to a single address (/32 or /128), might it break anything?

Upstream bug: https://bugs.launchpad.net/neutron/+bug/1622654

Revision history for this message
Ann Taraday (akamyshnikova) wrote :

I was not able to reproduce this issue on 9.0 and 10.0 (iso 687) envs. Can you please check my steps http://paste.openstack.org/show/573545/ if something is missing?

Changed in mos:
status: New → Incomplete
Revision history for this message
Danil Akhmetov (dinobot) wrote :

Yes, there is an important update:

the issue requires security groups configured to use ipset, and issue was originally hit in 'default' security group (which also uses ipset out of the box in MOS)

Changed in mos:
status: Incomplete → Confirmed
importance: Undecided → High
assignee: nobody → MOS Neutron (mos-neutron)
description: updated
Revision history for this message
Ann Taraday (akamyshnikova) wrote :

Actually problem appears for security groups which has allowed pair address on port with big cidr as remote security group. As default security group has itself as remote security group this simply reproduced with it.

And some more: to have ping for all VMs from in that security group you need to have rule that allow ICMP(or any) for that remote security group. (we have this from the beginning in default security group)

Here is paste http://paste.openstack.org/show/589868/

Revision history for this message
Ann Taraday (akamyshnikova) wrote :

The main misunderstanding with this issue is that when we add allowed pair address for one port - we add this allowed pair for all ports in security group (if it has itself as remote), so this behavior is expected. Probably, security groups should be configured differently and some notes about this should be added in documentation.

What we can do here - change current behavior and make adding allowed pair in ipset optional, but change won't be backportable, so it will be available only since Ocata(if it will make it there).

Revision history for this message
Ann Taraday (akamyshnikova) wrote :

I've tried to check whether there is the way to do something backportable and there is not.

Now, allowed pair is added in ipset - so either all members of security group are available or no one. From the point of upstream - making allowed pair to have access only to one port more like feature request, as current behavior was presumed from the beginning and should be supported as well.

Changed in mos:
assignee: Ann Taraday (akamyshnikova) → Inessa Vasilevskaya (ivasilevskaya)
Changed in mos:
status: In Progress → Won't Fix
Revision history for this message
Inessa Vasilevskaya (ivasilevskaya) wrote :

Unfortunately upon discussing this it seems the most we can do here is to cover this behavior with a test and document it better. Closing this as won't fix.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.