Hello,
I'm new to firewalld which I'm running on RHEL 8.6 x86_64 (firewalld-0.9.3-13) with nftables-0.9.3-25 backend.
I previously used nftables.services (so without firewalld as services conflict) to reject some basic outgoing traffic depending on the meta packet attribute skuid != root
The problem is that on hosts running docker, any update to my rules would flush docker related rules, hence my exploring of firewalld to see if both can live happily together.
My understanding is that firewalld policy (even for the HOST virtual zone configured as ingress zone for a policy) cannot express a match on such an attribute. Is this correct ?
Anyway, my readings of firewalld docs lead me to the following questions:
1) my understanding is that a "real" (non virtual) zone (can) embedds some firewall logic/rules for *incoming* traffic to the *host* (running firewalld) - the so called implicit zone policy, and that policies are meant to handle traffic between 2 zones (one called the ingress zone for whats' coming into the firewall and one called the egress zone for what's leaving the firewall). And that to handle traffic coming from/to the host (as in input/ouput Netfilter hooks) the HOST virtual zone can be used (as ingres OR egress but not both)
a) if HOST is used as egress : would not that overlap or even conflict with what's coming inside the host throught a real active zone ?
b) if one wants to apply rules for both incoming and outcoming traffic how should he use (ingress or egress) the HOST zone ? Do we have to write 2 policies ?
c) if a policy declares only one zone instead of both an ingress and an egress zone: is the second one similar the ANY virtual zone ?
2) I wonder how docker does its magic with firewalld :
a) how does the docker0 bridge interface get bound to the docker zone ?
b) why do docker nftables rules survive either:
a systemctl reload or restart of firewalld a firewall-cmd --reload or --complete-reload
what's the difference between this and doing some runtime (non --permanent) change ?
Thanks for your help
On Thu, Sep 14, 2023 at 08:49:51PM +0200, Thomas HUMMEL wrote:
Hello,
I'm new to firewalld which I'm running on RHEL 8.6 x86_64 (firewalld-0.9.3-13) with nftables-0.9.3-25 backend.
I previously used nftables.services (so without firewalld as services conflict) to reject some basic outgoing traffic depending on the meta packet attribute skuid != root
The problem is that on hosts running docker, any update to my rules would flush docker related rules, hence my exploring of firewalld to see if both can live happily together.
My understanding is that firewalld policy (even for the HOST virtual zone configured as ingress zone for a policy) cannot express a match on such an attribute. Is this correct ?
Correct. There is no support for matching skuid.
Anyway, my readings of firewalld docs lead me to the following questions:
- my understanding is that a "real" (non virtual) zone (can) embedds some
firewall logic/rules for *incoming* traffic to the *host* (running firewalld)- the so called implicit zone policy, and that policies are meant to handle traffic between 2 zones (one called the ingress zone for whats' coming into the firewall and one called the egress zone for what's leaving the firewall). And that to handle traffic coming from/to the host (as in input/ouput Netfilter hooks) the HOST virtual zone can be used (as ingres OR egress but not both)
Correct.
a) if HOST is used as egress : would not that overlap or even conflict with what's coming inside the host throught a real active zone ?
False. It's would function the same as a zone. Whether it executes before or after the zone depends on the policy priority. < 0 means before zones. > 0 means after zones.
b) if one wants to apply rules for both incoming and outcoming traffic how should he use (ingress or egress) the HOST zone ? Do we have to write 2 policies ?
Yes. It must be two policies.
policyA (INPUT): ingress-zones: <zone> egress-zones: HOST
policyA (OUTPUT): ingress-zones: HOST egress-zones: <zone>
c) if a policy declares only one zone instead of both an ingress and an egress zone: is the second one similar the ANY virtual zone ?
A policy is only active if both ingress-zones and egress-zones contain an active zone (or the special HOST/ANY).
- I wonder how docker does its magic with firewalld :
It depends on the docker and firewalld version. It's changed gradually over time.
a) how does the docker0 bridge interface get bound to the docker zone ?
Docker communicates with firewalld over dbus. It basically does a "--zone docker --change-zone-of-interface docker0".
b) why do docker nftables rules survive either:
Do you mean "docker" zone?
The docker zone is a native to firewalld. It goes active when an interface, e.g. docker0, is added to the zone.
a systemctl reload or restart of firewalld a firewall-cmd --reload or --complete-reload
Docker may notice the firewalld restart and then re-add docker0 to the docker zone. At least, it should. :)
what's the difference between this and doing some runtime (non --permanent) change ?
Nothing. Adding the interface to the docker zone _is_ a runtime change done by docker.
Hope that helps. Eric.
On 9/15/23 20:47, Eric Garver wrote:
On Thu, Sep 14, 2023 at 08:49:51PM +0200, Thomas HUMMEL wrote:
Hello,
Hello and thanks for your detailed answer.
a) if HOST is used as egress : would not that overlap or even conflict with what's coming inside the host throught a real active zone ?
False. It's would function the same as a zone. Whether it executes before or after the zone depends on the policy priority. < 0 means before zones. > 0 means after zones.
Ok. So, in order to filter both incoming/outgoing traffic to/from the host, what's the best practice :
a) 2 HOST policies : egress *in addition* to the zone implicit policy handling INPUT ingress handling OUTPUT or b) only one HOST (ingress) policy to handle OUTPUT + only the zone implicit policy to handle INPUT ?
c) if a policy declares only one zone instead of both an ingress and an egress zone: is the second one similar the ANY virtual zone ?
A policy is only active if both ingress-zones and egress-zones contain an active zone (or the special HOST/ANY).
Ok, I was surprised the syntax grammar made those fields optionnal
a) how does the docker0 bridge interface get bound to the docker zone ?
Docker communicates with firewalld over dbus. It basically does a "--zone docker --change-zone-of-interface docker0".
ok so I guess docker is aware somehow it is running in a firewalld environment
b) why do docker nftables rules survive either:
Do you mean "docker" zone?
No I meant the nft chains I can see with 'nft list ruleset' which is what ultimately make docker "work" but I guess you answered that further with this :
"Docker may notice the firewalld restart and then re-add docker0 to the docker zone. At least, it should. :)"
That's the dynamic behavior I was looking into because nftable alone + docker cannot do it. So my intent was to mix this docker handling as is and add some HOST policies to replicate my permanent existing nftable rules so both live happily together across reloads/restarts (unfortunately I'm using the skuid meta information...)
Thanks again for your help
On Mon, Sep 18, 2023 at 12:19:58PM +0200, Thomas HUMMEL wrote:
On 9/15/23 20:47, Eric Garver wrote:
On Thu, Sep 14, 2023 at 08:49:51PM +0200, Thomas HUMMEL wrote:
Hello,
Hello and thanks for your detailed answer.
a) if HOST is used as egress : would not that overlap or even conflict with what's coming inside the host throught a real active zone ?
False. It's would function the same as a zone. Whether it executes before or after the zone depends on the policy priority. < 0 means before zones. > 0 means after zones.
Ok. So, in order to filter both incoming/outgoing traffic to/from the host, what's the best practice :
a) 2 HOST policies : egress *in addition* to the zone implicit policy handling INPUT ingress handling OUTPUT or b) only one HOST (ingress) policy to handle OUTPUT + only the zone implicit policy to handle INPUT ?
They're functionally equivalent. It's a matter of preference.
Personally I prefer my rules in policies and only use zones to group interfaces/sources, i.e. no/minimal rules in zones. But I authored the policies feature, so I'm a bit bias. ;)
c) if a policy declares only one zone instead of both an ingress and an egress zone: is the second one similar the ANY virtual zone ?
A policy is only active if both ingress-zones and egress-zones contain an active zone (or the special HOST/ANY).
Ok, I was surprised the syntax grammar made those fields optionnal
a) how does the docker0 bridge interface get bound to the docker zone ?
Docker communicates with firewalld over dbus. It basically does a "--zone docker --change-zone-of-interface docker0".
ok so I guess docker is aware somehow it is running in a firewalld environment
Yes. It has to be. It communicates with firewalld over dbus. It will see a dbus "Reloaded()" signal from firewalld.
b) why do docker nftables rules survive either:
Do you mean "docker" zone?
No I meant the nft chains I can see with 'nft list ruleset' which is what ultimately make docker "work" but I guess you answered that further with this :
"Docker may notice the firewalld restart and then re-add docker0 to the docker zone. At least, it should. :)"
That's the dynamic behavior I was looking into because nftable alone + docker cannot do it. So my intent was to mix this docker handling as is and add some HOST policies to replicate my permanent existing nftable rules so both live happily together across reloads/restarts (unfortunately I'm using the skuid meta information...)
Thanks again for your help
See this upstream bug about skuid matching:
https://github.com/firewalld/firewalld/issues/725
tl;dr It's blocked on nftables supporting these matches on _INPUT_ to the firewalld node. IIRC, current support is OUTPUT only.
The reason INPUT support is required is because I envision using skuid/etc to be a zone source, e.g. --zone foobar --add-source=skuid:egarver. This would allow you to abstract a group of processes into a zone.
On 9/18/23 16:37, Eric Garver wrote:
Personally I prefer my rules in policies and only use zones to group interfaces/sources, i.e. no/minimal rules in zones. But I authored the policies feature, so I'm a bit bias. ;)
It makes sense to me as well. Different objects for different purpose : zone to split the network, policies to handle traffic between splitted parts.
The reason INPUT support is required is because I envision using skuid/etc to be a zone source, e.g. --zone foobar --add-source=skuid:egarver. This would allow you to abstract a group of processes into a zone.
Ok. And supporting OUTPUT only in firewalld would interfere for later support on skuid like zones I guess.
Thanks for your help
firewalld-users@lists.fedorahosted.org
-
Eric Garver -
Thomas HUMMEL