[libvirt] [PATCH] nwfilter: Support for learning a VM's IP address

[Stefan Berger]

"Daniel P. Berrange" <berrange at redhat.com> wrote on 03/31/2010 03:44:48 
PM:

> Please respond to "Daniel P. Berrange"
> 
> On Tue, Mar 30, 2010 at 01:56:52PM -0400, Stefan Berger wrote:
> > Subject: Support for learning a VM's IP address
> 
> > A caveat: The algorithm does not know which one is the appropriate IP
> > address of a VM. If the VM spoofs an IP address in its first ARP 
traffic
> > or IPv4 packets its filtering rules will be instantiated for this IP
> > address, thus 'locking' it to the found IP address. So, it's still
> > 'safer' to explicitly provide the IP address of a VM's interface in 
the
> > filter description if it is known beforehand.
> 
> While this code is very clever, I'm not really convinced that having a
> learning capability that snifs arbitrary IP packets for an address is
> desirable. The primary task of the nwfilter mechanism is to provide 
secure
> isolation of the VM from other VMs & network protocols. Basing this 
ontop 
> of a learning mode that we know can be trivially poisoned/exploited by 
> sending fake ARPs just doesn't seem like a good plan - it is providing 
> users a false sense of security.

That's correct. It mostly provides 'convenience'.

> 
> The only way I could see this working in a reasonably secure manner is 
to
> start from the assigned MAC address that we know & can trust. Then 
listen for
> DHCP OFFERS (IPv4/6) matching the MAC address, and extract the IP from 
that.

I am actually doing that, though I am only comparing the destination MAC 
address
in that case so far and not the MAC address in the DHCP OFFER itself. The 
DHCP response
is unicasted, so I don't currently compare the MAC address in the DHCP 
OFFER, but 
that would be trivial to add.

The problem with libpcap is that the sockets it is using don't give a 
guarantee that
none of the packets will be missed -- afaik. Missing that one DHCP OFFER 
could then be fatal
and waiting for the lease timeout probably not an option. Are there other 
options?

I'd like to keep the algorithm as much as possible as it is now but be 
able to tell
the thread to only look for dhcp offers for example, provided that this 
could be
done in a reliable manner. If a trusted DHCP server was provided, the 
thread could
be acting this way, otherwise it could rely on ARP, IPv4 or DHCP Offer. It 
would 
be a matter of configuration of libvirt how the learning actually works.

> This assumes DHCP OFFERS come from a trusted server, so we need to make 
sure
> that other VMs can't spoof DHCP OFFERS. Either the admin could include a
> DHCP blocking rule in the nwfilter config for all VMs (needs to be on 
all
> hosts), or have a host config parameter for nwfilter to specify the 
trusted 
> DHCP server address. If done right, this gives a IP addr learning mode 
which
> the VM can't poison with an IP of its choosing.

Only the missing of packets is fatal...

> 
> For IPv6 the network might use DHCPv6 which we can procss in much the 
same
> way, or it might be doing stateless autoconfig. So we'd need some host 
level
> config parameter to specify whether to learn based on DHCPv6, or based 
on
> the router advertisments. In the latter case a VM auto-assigns  itself 
an
> IPv6 address based on the router prefix + its MAC address. So if we spot
> the router prefix + know the MAC addr we can safely set the IPv6 addr 
filter

The issue with looking out for multiple parameters, i.e., IP and IPv6 (as 
well know
address parameters) is that if only one parameter was found a partial 
instantiation of 
the filters would be possible. I don't support something like this at the 
moment, so
I would only want to wait for one parameter 'IP'... :-/ Also waiting for 
IP or
IPv6 while the other is already known could take some time...

Regards,
   Stefan

> 
> Regards,
> Daniel
> -- 
> |: Red Hat, Engineering, London    -o-   
http://people.redhat.com/berrange/:|
> |: http://libvirt.org -o- http://virt-manager.org -o- 
http://deltacloud.org:|
> |: http://autobuild.org        -o-         
http://search.cpan.org/~danberr/:|
> |: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 
9505 :|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100331/3d2b249e/attachment-0001.htm>