"Daniel P. Berrange" <berrange@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 :|