<div dir="ltr"><div dir="ltr">Thanks for the comprehensive answer.<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 4:49 PM Laine Stump <<a href="mailto:laine@laine.org">laine@laine.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/20/18 10:17 AM, Daniel P. Berrangé wrote:<br>
> On Tue, Nov 20, 2018 at 04:05:43PM +0100, Marcin Mirecki wrote:<br>
>> Hello,<br>
>><br>
>> The network filters feature has an option of automatically detecting the IP<br>
>> of a VM [1].<br>
>> Is it possible to retrieve this IP by any means?<br>
> It is possibly visible in the live XML in the <filterref> XML as a<br>
> parameter.<br>
<br>
<br>
It would be kind of cool if it did, but alas it does not. As far as I<br>
can tell the variables/parameters in nwfilter rules are a one way street<br>
- stuff that's set automatically by the driver are not reflected back to<br>
the hypervisor for its dumpxml (nor to the nwfilter-bindings-dumpxml).<br>
<br>
<br>
<br>
>> If not, would you considering adding such a feature?<br>
> We should make it visible via the API for fetching guest IP addrs.<br>
<br>
<br>
It would be neat, but I don't know how much info it would actually give<br>
us (see below).<br>
<br>
<br>
><br>
> The snooping code should be moved out of nwfilter and into the<br>
> QEMU driver.<br>
<br>
<br>
That would:<br>
<br>
<br>
1) only work when the domain is defined in qemu:///system (emphasis on<br>
the _system_ part), so in our future utopia where qemu:///session<br>
domains have access to all of the same networking as qemu:///system,<br>
this code would not work.<br>
<br>
<br>
2) only work when the domain is defined in qemu:///system (emphasis on<br>
the _qemu_ part), so xen, libxl, etc, would left out in the cold.<br>
<br>
<br>
For those reasons, I think it would be better suited to<br>
network:///system or nwfilter:///system.<br>
<br>
<br>
Also, due to the extra overhead in having pcap examine every packet, we<br>
don't want to ever actually setup the pcap socket for this unless there<br>
is an nwfilter that uses it.<br>
<br>
<br>
Finally, we should look at the trustability of this information, and<br>
what are the cases that the info wouldn't be available from somewhere else:<br>
<br>
<br>
1) in the case of nwfilter snooping ARP packets, the results of all of<br>
those can be found by examining the ARP cache on the host, and there is<br>
already a mode of virsh domifaddr that looks to the ARP cache ("virsh<br>
ifaddr --source arp").<br>
<br>
<br>
2) for guests that are doing DHCP on a libvirt virtual network, the<br>
results of that are already available from "virsh domifaddr --source<br>
leases".<br></blockquote><div><br></div><div>Unfortunately it's not likely that libvirt dhcp will be used in the solution.</div><div>We have one vm per libvirt instance (it's kubevirt), and the interfaces</div><div>will rather be managed by some sdn solution like OVN.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
3) for guests that are connected to a host bridge that's directly<br>
connected to the physical network, and getting a DHCP address from an<br>
external DHCP server, those results can also be seen in the ARP cache<br>
("virsh domifaddr --source arp").<br></blockquote><div><br></div><div><div><br class="gmail-Apple-interchange-newline">The vm is connected to a bridge on the host, with no L3 traffic</div><div>to the host, so the arp tables on the host don't have the required entries.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> The QEMU driver should simply update the nwfilter<br>
> binding with the IP  once it has snooped it.<br>
><br>
>> It would be very useful for uses cases where there is no guest agent.<br>
> NB, there are potentially trust issues when using a snooped IP addr.<br>
><br>
> eg if snooping DHCP responses, a malicious guest could act as a DHCP<br>
> server  and send bogus responses.   If snooping ARPs a malicious<br>
> guest can send gratuituous ARPs. Thus for nwfilter we tend to recommend<br>
> setting explicit IP addrs, or using filters that block guests from<br>
> sending bogus DHCP response<br>
<br>
<br>
Agreed. Of course the info in the ARP cache can be poisoned with<br>
incorrect data, but so can the results that come from snooping the tap<br>
device for ARP packets (both of them in the same manner, actually). So<br>
(to get back to my suggestion above) I don't think it would be lowering<br>
security at all to use results from the ARP cache vs results from<br>
snooping dhcp/arp packets from the tap device.<br>
<br>
<br>
</blockquote></div></div></div></div>