[libvirt] Reporting of IP detected by network filter

[Marcin Mirecki]

Thanks for the comprehensive answer.


On Tue, Nov 20, 2018 at 4:49 PM Laine Stump <laine at laine.org> wrote:

> On 11/20/18 10:17 AM, Daniel P. Berrangé wrote:
> > On Tue, Nov 20, 2018 at 04:05:43PM +0100, Marcin Mirecki wrote:
> >> Hello,
> >>
> >> The network filters feature has an option of automatically detecting
> the IP
> >> of a VM [1].
> >> Is it possible to retrieve this IP by any means?
> > It is possibly visible in the live XML in the <filterref> XML as a
> > parameter.
>
>
> It would be kind of cool if it did, but alas it does not. As far as I
> can tell the variables/parameters in nwfilter rules are a one way street
> - stuff that's set automatically by the driver are not reflected back to
> the hypervisor for its dumpxml (nor to the nwfilter-bindings-dumpxml).
>
>
>
> >> If not, would you considering adding such a feature?
> > We should make it visible via the API for fetching guest IP addrs.
>
>
> It would be neat, but I don't know how much info it would actually give
> us (see below).
>
>
> >
> > The snooping code should be moved out of nwfilter and into the
> > QEMU driver.
>
>
> That would:
>
>
> 1) only work when the domain is defined in qemu:///system (emphasis on
> the _system_ part), so in our future utopia where qemu:///session
> domains have access to all of the same networking as qemu:///system,
> this code would not work.
>
>
> 2) only work when the domain is defined in qemu:///system (emphasis on
> the _qemu_ part), so xen, libxl, etc, would left out in the cold.
>
>
> For those reasons, I think it would be better suited to
> network:///system or nwfilter:///system.
>
>
> Also, due to the extra overhead in having pcap examine every packet, we
> don't want to ever actually setup the pcap socket for this unless there
> is an nwfilter that uses it.
>
>
> Finally, we should look at the trustability of this information, and
> what are the cases that the info wouldn't be available from somewhere else:
>
>
> 1) in the case of nwfilter snooping ARP packets, the results of all of
> those can be found by examining the ARP cache on the host, and there is
> already a mode of virsh domifaddr that looks to the ARP cache ("virsh
> ifaddr --source arp").
>
>
> 2) for guests that are doing DHCP on a libvirt virtual network, the
> results of that are already available from "virsh domifaddr --source
> leases".
>

Unfortunately it's not likely that libvirt dhcp will be used in the
solution.
We have one vm per libvirt instance (it's kubevirt), and the interfaces
will rather be managed by some sdn solution like OVN.


>
> 3) for guests that are connected to a host bridge that's directly
> connected to the physical network, and getting a DHCP address from an
> external DHCP server, those results can also be seen in the ARP cache
> ("virsh domifaddr --source arp").
>


The vm is connected to a bridge on the host, with no L3 traffic
to the host, so the arp tables on the host don't have the required entries.



>
>
> > The QEMU driver should simply update the nwfilter
> > binding with the IP  once it has snooped it.
> >
> >> It would be very useful for uses cases where there is no guest agent.
> > NB, there are potentially trust issues when using a snooped IP addr.
> >
> > eg if snooping DHCP responses, a malicious guest could act as a DHCP
> > server  and send bogus responses.   If snooping ARPs a malicious
> > guest can send gratuituous ARPs. Thus for nwfilter we tend to recommend
> > setting explicit IP addrs, or using filters that block guests from
> > sending bogus DHCP response
>
>
> Agreed. Of course the info in the ARP cache can be poisoned with
> incorrect data, but so can the results that come from snooping the tap
> device for ARP packets (both of them in the same manner, actually). So
> (to get back to my suggestion above) I don't think it would be lowering
> security at all to use results from the ARP cache vs results from
> snooping dhcp/arp packets from the tap device.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20181121/b04e490e/attachment-0001.htm>