Re: [libvirt] [PATCH] nwfilter: Support for learning a VM's IP address
"Daniel P. Berrange" <berrange(a)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 :|
Attachments:
- attachment.html (text/html — 5.9 KB)