Nova calls into neutron as admin circumventing fixed-ip on shared network

[Aaron Rosen]

In Neutron on shared networks the default policy is to not allow tenants from specifying their own fixed ips. This is done so that one cannot deliberately try to imposter another tenant's instance after it has been deleted. The reason is working is because nova is calling into neutron as admin.

$quantum port-create --fixed-ip ip_address=10.2.0.44 shared-net
{"NeutronError": "Policy doesn't allow create_port to be performed."}

^Fails

$ nova boot --image cirros-0.3.1-x86_64-uec --nic net-id=abce62c9-2d83-42ea-ada2-fd24e14af842,v4-fixed-ip=10.2.0.44 --flavor 1 vm23
^Succeeds

Marking as a security vulnerability though it's probably not really a big deal.

[Aaron Rosen (arosen)]

Unfortinately, there doesn't seem to be an easy way to fix this. If a plugin has the port-bindings extension loaded nova-compute needs to call into neutron ad admin to set these values. Probably a nothing reason why creating the port on the nova-compute node is a bad idea...

[Aaron Rosen (arosen)]

I have a patch for this. Should I just upload it to the public gerrit? I don't think this is a huge vulnerability. @Mark McClain/all - what do you think?

[Mark McClain (markmcclain)]

Thought about this more over dinner. I think it falls on the side of important bug and not a critical security issue for a couple of reasons.

1) The tenant is legally allocating a resource (port) that they have rights to create.

2) This is not the only method to obtain a targeted IP. Given the right timing and quota limits, a tenant could obtain a specific address via a sequence of floating IP allocation/deallocation calls and VM boots.

3) Obtaining a floating IP from a shared pool is the only way In a true multi-tenant public environment to prevent this kind of reuse attack. The documentation should steer users who want a certain IP away from pecifying the preferred address on the shared network at boot because the results are not necessarily repeatable. When a tenant returns an IP to the allocation pool, there is very little we can do because there is not a good way to understand the 'value' of the IP.

[Jeremy Stanley (fungi)]

Agreed this seems less like a security vulnerability in the software and more of a deployment architecture choice. Ultimately, if the deployer wishes to securely allow a tenant to select specific addresses, then that tenant needs their own dedicated global assignment (with provider network isolation at layer 2 and 3 if there's no translation in place to achieve such an effect).

[Aaron Rosen (arosen)]

Sounds good to me. The only reason I marked this as a security vulnerability is that in the policy.json file for neturon we specify:

    "create_port:fixed_ips": "rule:admin_or_network_owner",

In the case of creating a port on a shared network one via nova can set the fixed_ips where they can't do it directly through neutron. This is because nova is calling into neutron as admin.

That said, to fix this issue we would need to change nova/network/neturon/api.py to do a create_port() as nonAdmin (passing in the allocated fixed ips). Then see if it succeeded depending on the security policy set in neurton. Then call update_port as admin to set the port_bindings (Yuck!). In Icehouse I hope to help improve this integration between nova and neturon. For now my vote would be just to release note it.

[Thierry Carrez (ttx)]

Will open this unless someone complains before tomorrow.

[Kurt Seifried (kseifried)]

Does this issue need a CVE?

[Aaron Rosen (arosen)]

Moving to wish list as this really isn't that bad and the fix isn't very feasible right now due to the port-binding extension requires one to be admin.

[Markus Zoeller (markus_z) (mzoeller)]

This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on.