Thanks for the comprehensive answer.
The vm is connected to a bridge on the host, with no L3 traffic
On Tue, Nov 20, 2018 at 4:49 PM Laine Stump <laine@xxxxxxxxx> 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.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
