Bug #2047

Attaching arbitrary IP addresses using one.vm.attachnic

Added by Simon Boulet about 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:05/15/2013
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Core & System
Target version:Release 4.4
Resolution:fixed Pull request:
Affected Versions:OpenNebula 4.0

Description

Its seems a user can attach any arbitrary IP address to a VM by calling one.vm.attachnic without specifying a NETWORK_ID (or NETWORK).

one.vm.attachnic(key, vm_id, "NIC=[IP=1.2.3.4]")

Would attach the arbitrary address 1.2.3.4 to the VM.

I'm not sure if that's the expected behaviour.

I can see this being a major issue for hypervisors not enforcing VLAN or bridge isolation (ie. configuring all VM in the same VLAN). It can typically be used by a user to grab an existing IP address from the network (such as gateway address or IP addresses assigned to other VMs).

opennebula-attachnic-enforce-network.patch Magnifier (880 Bytes) Simon Boulet, 05/15/2013 12:45 AM

opennebula-attachnic-enforce-network.patch Magnifier - Got bug # reference wrong in commit message of the first patch (880 Bytes) Simon Boulet, 05/15/2013 12:58 AM

Associated revisions

Revision 964def4b
Added by Carlos Martín over 7 years ago

Bug #2047: Add NIC/BRIDGE as a default restricted attribute

Revision 5abd4300
Added by Carlos Martín over 7 years ago

Bug #2047: Add NIC/BRIDGE as a default restricted attribute
(cherry picked from commit 964def4bc3a72aa1f7be7b4e892dc902dd6db254)

History

#3 Updated by Ruben S. Montero about 8 years ago

But this is not only for attach NIC you could also do the same with a one.template.create or one.vm.create. Maybe we can check for restricted attributes when attaching a NIC...

#4 Updated by Simon Boulet about 8 years ago

I'm not sure why VMs are allowed to use IP addresses that aren't part of a VNET?

#5 Updated by Ruben S. Montero about 8 years ago

Well, I was thinking exactly the same when I wrote my last comment.

  • first, we need a way to have "network-less" NICs. This can be done with MAC (as in NIC=[MAC="00:01.."]). This can be limited with the RESTRICTED attributes.
  • So, the same can be applied to IP, I can restricted IP so only oneadmin can do NIC=[IP="192.168..."] (note that this is equivalent to the MAC-form).I can restricted that (putting IP as a RESTRICTED attribute in oned.conf), but then I'd also restrict NIC=[NETWORK="blue",IP="192.."] which probably is a valid entry.

So I'm inclined to agree with you, IP does not make sense without a NETWORK attribute in a NIC. (Because if it makes sense you can always use MAC)

#6 Updated by Ruben S. Montero about 8 years ago

  • Category set to Core & System
  • Status changed from Pending to New
  • Target version set to Release 4.2

So here the real problem is to use BRIDGE, setting up a NIC not attached to any particular interface would not be a problem. In fact I think it fails so we do not pass the SOURCE option for the attach nic command.

This issue will be solved by:

1.- First check for restricted attributes in NIC template

2.- Check that all needed attributes are available (MAC/IP and BRIDGE)

#7 Updated by Ruben S. Montero almost 8 years ago

  • Target version changed from Release 4.2 to Release 4.4

#8 Updated by Carlos Martín over 7 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

Hi Simon,

We've been talking about this, and it looks to us that the only real problem is if you let a user choose a mac/ip and attach the nic to a bridge. So for now we have added NIC/BRIDGE as a default restricted attribute in oned.conf.

Let us know if you still see any other problems we may have missed.

Cheers

Also available in: Atom PDF