<tt>"Daniel P. Berrange" <berrange@redhat.com> wrote on 03/31/2010 03:44:48 PM: > Please respond to "Daniel P. Berrange"</tt> <tt>> > 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.</tt> <tt>That's correct. It mostly provides 'convenience'.</tt> <tt> > > 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.</tt> <tt>I am actually doing that, though I am only comparing the destination MAC address</tt> <tt>in that case so far and not the MAC address in the DHCP OFFER itself. The DHCP response</tt> <tt>is unicasted, so I don't currently compare the MAC address in the DHCP OFFER, but </tt> <tt>that would be trivial to add.</tt> <tt>The problem with libpcap is that the sockets it is using don't give a guarantee that</tt> <tt>none of the packets will be missed -- afaik. Missing that one DHCP OFFER could then be fatal</tt> <tt>and waiting for the lease timeout probably not an option. Are there other options?</tt> <tt>I'd like to keep the algorithm as much as possible as it is now but be able to tell</tt> <tt>the thread to only look for dhcp offers for example, provided that this could be</tt> <tt>done in a reliable manner. If a trusted DHCP server was provided, the thread could</tt> <tt>be acting this way, otherwise it could rely on ARP, IPv4 or DHCP Offer. It would </tt> <tt>be a matter of configuration of libvirt how the learning actually works.</tt> <tt> > 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.</tt> <tt>Only the missing of packets is fatal...</tt> <tt>> > 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</tt> <tt>The issue with looking out for multiple parameters, i.e., IP and IPv6 (as well know</tt> <tt>address parameters) is that if only one parameter was found a partial instantiation of </tt> <tt>the filters would be possible. I don't support something like this at the moment, so</tt> <tt>I would only want to wait for one parameter 'IP'... :-/ Also waiting for IP or</tt> <tt>IPv6 while the other is already known could take some time...</tt> <tt>Regards,</tt> <tt> Stefan</tt> <tt> > > Regards, > Daniel > -- > |: Red Hat, Engineering, London -o- </tt><a href=http://people.redhat.com/berrange/:|><tt>http://people.redhat.com/berrange/:|</tt></a><tt> > |: </tt><a href=http://libvirt.org/><tt>http://libvirt.org</tt></a><tt> -o- </tt><a href="http://virt-manager.org/"><tt>http://virt-manager.org</tt></a><tt> -o- </tt><a href=http://deltacloud.org:|/><tt>http://deltacloud.org:|</tt></a><tt> > |: </tt><a href=http://autobuild.org/><tt>http://autobuild.org</tt></a><tt> -o- </tt><a href=http://search.cpan.org/~danberr/:|><tt>http://search.cpan.org/~danberr/:|</tt></a><tt> > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| </tt>