[libvirt] [PATCH] nwfilter: Support for learning a VM's IP address
Stefan Berger
stefanb at us.ibm.com
Wed Mar 31 20:10:36 UTC 2010
"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>
More information about the libvir-list
mailing list