Re: [PATCH v3 00/27] [PATCH v3 00/27] native support for nftables in virtual network driver

On Thu, Apr 25, 2024 at 06:22:33PM +0100, Daniel P. Berrangé wrote: > On Thu, Apr 25, 2024 at 01:38:06AM -0400, Laine Stump wrote: >> V2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5R... >> >> This patch series enables libvirt to use nftables rules rather than >> iptables *when setting up virtual networks* (it does *not* add >> nftables support to the nwfilter driver). > > I deployed on my machine and restarted virtnetworkd, with nft backend > active. I have 2 networks running, and got the following result > > table ip libvirt { > chain INPUT { > type filter hook input priority filter; policy accept; > counter packets 363 bytes 30801 jump LIBVIRT_INP > } > > chain FORWARD { > type filter hook forward priority filter; policy accept; > counter packets 1 bytes 76 jump LIBVIRT_FWX > counter packets 1 bytes 76 jump LIBVIRT_FWI > counter packets 1 bytes 76 jump LIBVIRT_FWO > } > > chain OUTPUT { > type filter hook output priority filter; policy accept; > counter packets 286 bytes 107221 jump LIBVIRT_OUT > } > > chain LIBVIRT_INP { > iifname "virbr0" udp dport 53 counter packets 0 bytes 0 accept > iifname "virbr0" tcp dport 53 counter packets 0 bytes 0 accept > iifname "virbr0" udp dport 67 counter packets 1 bytes 320 accept > iifname "virbr0" tcp dport 67 counter packets 0 bytes 0 accept > iifname "virbr1" udp dport 53 counter packets 0 bytes 0 accept > iifname "virbr1" tcp dport 53 counter packets 0 bytes 0 accept > iifname "virbr1" udp dport 67 counter packets 0 bytes 0 accept > iifname "virbr1" tcp dport 67 counter packets 0 bytes 0 accept > } > > chain LIBVIRT_OUT { > oifname "virbr0" udp dport 53 counter packets 0 bytes 0 accept > oifname "virbr0" tcp dport 53 counter packets 0 bytes 0 accept > oifname "virbr0" udp dport 68 counter packets 1 bytes 336 accept > oifname "virbr0" tcp dport 68 counter packets 0 bytes 0 accept > oifname "virbr1" udp dport 53 counter packets 0 bytes 0 accept > oifname "virbr1" tcp dport 53 counter packets 0 bytes 0 accept > oifname "virbr1" udp dport 68 counter packets 0 bytes 0 accept > oifname "virbr1" tcp dport 68 counter packets 0 bytes 0 accept > } I'm wondering if these DHCP and DNS rules are in fact pointless. In iptables, there's 1 set of global tables, and other firewall tools or sysadmin might have put a DENY/REJECT that catches DHCP/DNS. We inserted libvirt rules at the head of the tables, so we can then explicitly ACCEPT DHCP/DNS, even if later rules would deny them. So the LIBVIRT_INP/LIBVIRT_OUT rules are useful in the context of iptables. In nftables, there are arbitrary many tables, and a packet needs to be allowed by *all* the tables, to continue its flow. If a non-libvirt tables has put in a DENY/REJECT that catches DHCP/DNS, then no matter what rules we put in the 'libvirt' tables, we can never undo that DENY/REJECT. So these LIBVIRT_INP/LIBVIRT_OUT rules are entirely pointless unless the 'libvirt' table had later rules that could be DENY/REJECTing DHCP/DNS. We don't today. The only way I see these DHCP/DNS rules being useful, is if the LIBVIRT_INP chain had a default 'deny' rule for 'virbr0', to block the guest from all access to the host. That would to some extent overlap with a general host firewall tool, but there might not be one. Currently our "isolated" config still allows guests to access the host, just won't route off host. I guess any of the forward modes could conceptually have a "deny host" access rule. Still, even if we implemented this "deny host" concept, we still don't need to add these DHCP/DNS rules to LIBVIRT_INP and LIBVIRT_OUT, unless 'deny host' is actually active. IOW, I think we should delete (or comment out) all the DHCP/DNS rules from your nftables impl currently.