qubes-core-agent: remove conflict with firewalld

[3nprob]

Currently, qubes-core-agent does not allow installation alongside firewalld. They seem to get along as fine as one would expect when allowed, though. Users should be allowed to use it if they want.

[marmarek]

None of firewall services in qubes (qubes-firewall.service, qubes-iptables.service (which actually uses nft...), qubes-antispoof.service) work fine with firewalld. They will override rules set by the other, or at least add conflicting rules. While in some situations it may appear they "get along fine", the actual result is usually firewall not blocking things it should block, or blocking too much.

So, no, don't just remove the conflict. If you want to use firewalld, all of the mentioned services need to be adjusted to consider presence of firewalld and coordinate adding rules with them.

[3nprob]

None of firewall services in qubes (qubes-firewall.service, qubes-iptables.service (which actually uses nft...), qubes-antispoof.service) work fine with firewalld. They will override rules set by the other, or at least add conflicting rules. While in some situations it may appear they "get along fine", the actual result is usually firewall not blocking things it should block, or blocking too much.

The same could be said for docker, ufw, probably other commonly used packages?

If you want to use firewalld, all of the mentioned services need to be adjusted to consider presence of firewalld and coordinate adding rules with them.

Sure, if the user decides to concurrently run two services poking around in netfilter/iptables, making sure they are configured properly is on them. Currently the only way to even attempt that is to fork the package.

The use-case I have is setting up routing policies for vlans in a customized sys-net and so far I have not experienced conflicts like you describe when running the core qubes networking (sans NetworkManager) with this patch alongside firewalld on fedora 41.

[marmarek]

Try for example firewall-cmd --add-port=443/tcp - you'd expect traffic to 443 would be allowed after this command, but it won't be the case. That said, denying too much is usually safe (although may be surprising). With nft, it appears firewalld no longer removes tables/rules added by other tools (it was the case with iptables backend), so maybe it's a bit less bad nowadays.

As for other packages touching firewall, the thing about firewalld is it being commonly installed by default, and often used in various tutorials. Preventing its installation makes it obvious it won't work. If you get it running and then it doesn't work it's much more confusing behavior for users.

But since it appears it doesn't remove qubes-added rules anymore (at least not in default configuration), maybe some middle ground is to drop the conflict, but add a service drop-in to not start it by default unless explicitly enabled with qvm-service (similar to many other services)?

[3nprob]

The situation is indeed very different today with both packages on netfilter/nft compared to iptables and the transition.

But since it appears it doesn't remove qubes-added rules anymore (at least not in default configuration), maybe some middle ground is to drop the conflict, but add a service drop-in to not start it by default unless explicitly enabled with qvm-service (similar to many other services)?

Disabling by default makes sense.

@marmarek I just pushed an update to that effect - could you take a look? #581

(Aside: As a contributor I would find a "request for changes" a lot easier to work with and more constructive than immediate closure of PRs not fitting the bill (yet). Closing means I can't reuse the same branch and conversation becomes fragmented among more PRs than necessary)