I agree having different behavior is confusing. But as someone who regularly has to support problems with the xtables approach, it doesnt feel like that is much better to be honest.
I wonder if we shouldn’t just remove the service accept rules (leaving the snat rule) for nftables which would over time as people switched to nftables mean lxd wouldn’t be adding those rules at all. Then documenting what services and rules lxd requires.
They can have a default rule at the bottom. But we already have support for this via lxds acl feature. Which adds a configurable default action.
I edited my previous post and added information on how the configuration options could be and there would be an option to choose an insert position. The user can control that to bypass issues between different applications, but it would ultimately be configurable.
The issue is that it would probably still be better than both solutions 1 and 2 above.
If the user could configure to use regular tables, those accept rules would be used and important.
An accept would be as you mentioned previously: final for whateven chain it was inserted in.
I saw your updated example, thanks, it makes sense.
Yep we have something similar for xtables ipv4.nat.order but it only affects the Nat rule.
Adding ordering generally would only fix issues between applications if they start in a predictable order and are not reloaded after boot time.
Here is @stgraber post about this
This is why we are hesitant to change the approach at the moment until we can see how other firewall systems approach coexistence when using native nftables (rather than just calling the iptables shim).
I had proposed something similar to your suggestion previously
I can definitely see there might still be issues between different applications, but wouldn’t that problem still be smaller than not being able to have a hardened server or having to add all firewall rules by hand?
I have no clue on how to solve the ordering issue between different applications, but I still think my proposed solution solves some very problematic issues and doesn’t assume the behavior of other base chains. The correct base chain to jump from would be given by the user and the user can set that up and administer that as he wishes.
On my proposed solution, other than the ordering between rules from different applications, is there any other issue?
I chatted with @stgraber about this and we don’t want to make changes until we understand which direction the wider community are going in with regards to coexisting firewall rule sets. I am thinking of posting to the nftables mailing list asking about the thinking of the nftables namespaces given that a drop/reject in any of them prevents the other accept rules from taking effect. And whether they have any recommendations.
if you do, please post a link to the archive of that thread so we can follow along.
Thanks for the feedback!