Bug #2047
Attaching arbitrary IP addresses using one.vm.attachnic
Status: | Closed | Start date: | 05/15/2013 | |
---|---|---|---|---|
Priority: | Normal | Due 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).
Associated revisions
Bug #2047: Add NIC/BRIDGE as a default restricted attribute
Bug #2047: Add NIC/BRIDGE as a default restricted attribute
(cherry picked from commit 964def4bc3a72aa1f7be7b4e892dc902dd6db254)
History
#1 Updated by Simon Boulet about 8 years ago
- File opennebula-attachnic-enforce-network.patch added
#2 Updated by Simon Boulet about 8 years ago
- File opennebula-attachnic-enforce-network.patch added
#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