On 4/26/24 6:24 AM, Daniel P. Berrangé wrote:
> 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/5RTZ6PC3N3CO6X353QUHLVOL43SWQ4JD/
>>>
>>> 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.
This all makes sense. I'll try it out early next week along with the
changes to table/chain naming you suggested yesterday. (I would say
"this weekend", but it's springtime, which means "end of year" parties
are happening everywhere, and we have 3 of them we have to go to just
this weekend :-/)
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org