[OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713)

[Roman Podoliaka]

Upstream bug: https://bugs.launchpad.net/nova/+bug/1491307

I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following:

# /etc/nova.nova.conf on contrller node
[DEFAULT]
network_api_class = nova.network.api.API
security_group_api = nova

# /etc/nova/nova.conf on compute node
[DEFAULT]
network_api_class = nova.network.api.API
security_group_api = nova
firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver
network_manager = nova.network.manager.FlatDHCPManager
network_size = 254
allow_same_net_traffic = False
multi_host = True
send_arp_for_ha = True
share_dhcp_address = True
force_dhcp_release = True
flat_network_bridge = br100
flat_interface = eth0
public_interface = eth0

steps for test 1:
1) create and start VM instance-1 with secgroup default;
2) VM instance-1 ping br100: OK;
3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP)
4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
5) br100 ping VM instance-1: i got the same wrong message, not expected.

steps for test 2:
1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0;
2) create and start VM instance-2 with secgroup default;
3) br100 ping instance-2: OK

It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances?

[Fuel Devops McRobotson (fuel-devops-robot)]

Fix proposed to branch: openstack-ci/fuel-7.0/2015.1.0
Change author: Matt Riedemann <email address hidden>
Review: https://review.fuel-infra.org/16269

[Anna Babich (ababich)]

Nova-network is deprecated and isn't used in MOS 7.0, so move it to Invalid

[Anna Babich (ababich)]

The same as in previous comment is actual for MOS 8.0

[Denis Puchkin (dpuchkin)]

Anna, Nova-network used in MOS 7.0, when vcenter enabled

Bug not reproduced in 6.0 and 6.1 , because error in decorator function, in 6.0 and 6.1 this decorator not used with function "refresh_instance_ security_rules"

Invalid for mos 6.0 and 6.1
Confirmed for mos 7.0

[Fuel Devops McRobotson (fuel-devops-robot)]

Reviewed: https://review.fuel-infra.org/16269
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-ci/fuel-7.0/2015.1.0

Commit: 2e73744bd8b5ccc39bd30208237478eb9ae2f42f
Author: Matt Riedemann <email address hidden>
Date: Wed Mar 16 12:46:18 2016

Don't expect meta attributes in object_compat that aren't in the db obj

The object_compat decorator expects to get the Instance object with
'metadata' and 'system_metadata' attributes but if those aren't in the
db instance dict object, Instance._from_db_object will fail with a
KeyError.

In Kilo this happens per refresh_instance_security_rules because in the
compute API code, the instance passed to refresh_instance_security_rules
comes from the call to get the security group(s) which joins on the
instances column, but that doesn't join on the metadata/system_metadata
fields for the instances. So when the instances get to object_compat in
the compute manager and the db instance dict is converted to the
Instance object, it expects fields that aren't in the dict and we get
the KeyError.

The refresh_instance_security_rules case is fixed in Liberty per commit
12fbe6f082ef9b70b89302e15daa12e851e507a7 - in that case the compute API
passes Instance objects to the compute manager so object_compat doesn't
have anything to do, _load_instance just sees instance_or_dict isn't a
dict and ignores it.

We're making this change since (1) it's an obviously wrong assumption in
object_compat and should be fixed and (2) we need to backport this fix
to stable/kilo since it's an upgrade impact for users there.

Closes-Bug: #1533285

Change-Id: I36a954c095a9aa35879200784dc18e35edf689e6
(cherry picked from commit 08d1153d3be9f8d59aa0acc03eedd45a1697ed7b)

[TatyanaGladysheva (tgladysheva)]

Verification is postponed. Need env with VMware vSphere for testing.

[TatyanaGladysheva (tgladysheva)]

Verified on MOS 7.0 mu-3 updates.

Steps to verify:
1) create instance
2) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
3) check iptables on compute for created instance: iptables-save
4) add floating ip to instance and ping instance

Actual result:
1) ok
2) ok
3) iptables contain the following rule: nova-compute-inst-20 -p icmp -j ACCEPT
4) ping is ok

Iptables for existed instances are changing immediately if add/modify/delete security group.