Adding libvirt-daemon-config-nwfilter and critical filters by default to libvirt network interfaces

Hi all,

I have a suggestion that is based upon this ask.fedora thread, which contains some more information about the issue:

What do you think of adding libvirt-daemon-config-nwfilter to the dependencies of libvirt-daemon-driver-nwfilter (in both Workstation and Server)? libvirt-daemon-driver-nwfilter itself is already a dependency of qemu/kvm.

Additionally, I suggest to change the xml data that is added to vm-specific configuration files if new network interfaces are created, in order to include critical filters by default (such as no-arp-spoofing).

E.g., instead of adding an interface with

...
<interface type="network">
<mac address="52:54:00:05:e5:fd"/>
<source network="default"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
...

it should be added with the additional line <filterref filter=“no-arp-spoofing”/>:

...
<interface type="network">
<mac address="52:54:00:05:e5:fd"/>
<filterref filter="no-arp-spoofing"/>
<source network="default"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
...

My argument is that we should not assume that all admins who use qemu/kvm are aware of the absence of protection against things like ARP spoofing. The technology is also used by SMEs (internal use, smaller cloud providers, etc.) that do not have the sophisticated administration capabilities of the big corporations. Of course this is more an issue in the upstream distributions, but my opinion is that it makes sense to also tackle the issue in Fedora. I do not see a disadvantage in activating no-arp-spoofing by default (feel free to challenge this argument). Average Fedora users would also not be disadvantaged by more default security. The ask.fedora thread contains some more about this.

Another question would be if it makes sense to add further filters by default.

What do you think about it?

Sounds like a sensible suggestion to me. I suppose the best place to tackle this would be in Libvirt upstream directly, at libvirt · GitLab.

(Not that it’s wrong to talk about it here, though!)

1 Like

Assuming that the other bindings have the same behavior as the Python one, this seems to be not an issue for libvirt because its API does not extend the calls for new VMs. It returns an error if essential attributes are not set but does itself only automatically add the three major bus controller (usb,sata,pcie) as far as I tested it. I assume on libvirt's level, universal defaults and unasked/automated extensions may be problematic.

The creation of VMs with automatically/default configured network controllers, storages and such is done by virt-manager, gnome-boxes or cockpit.

I thought it makes sense to put the idea forward in here at first because it relates to multiple packages and another package dependency in the distribution.

But you are right, the upstreams seem to be more suitable to start.