-
Notifications
You must be signed in to change notification settings - Fork 18.9k
[25.0 backport] libnetwork/d/{bridge,overlay}: fix firewalld reload handling #50445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[25.0 backport] libnetwork/d/{bridge,overlay}: fix firewalld reload handling #50445
Conversation
|
Your first commit adds firewalld support to the Dockerfile / GHA workflows. It tooks us several attempts to get it right because there was nothing screaming at us when it's misconfigured. It looks good but I'd feel better if we're 100% sure that firewalld is really used by the daemon since it impacts security aspects of the daemon. Looking at the output of firewalld-enabled GHA jobs, I see that the dind image was correctly build with firewalld, but: 1. I'm not sure if that's enough to prove that the Engine was running in firewalld mode ; 2. GHA gc'd build artifacts so I can't look at the logs of daemons-under-test anyway. @corhere Did you try to check that? Maybe @robmry remembers if there's a way to prove that firewalld is correctly taken into account. |
It's fine ... In test (graphdriver) / integration (ubuntu-22.04), test TestFirewalldReloadNoZombies is skipped, because It passes in test (graphdriver) / integration (ubuntu-24.04, firewalld). |
70a1d42 to
58b4443
Compare
Signed-off-by: Rob Murray <[email protected]> (cherry picked from commit b8cacdf) Signed-off-by: Andrey Epifanov <[email protected]>
Doesn't look like it would ever have worked, but: - init the dbus connection to avoid a segv - include the chain name when creating the rule - remove the test rule if it's created Signed-off-by: Rob Murray <[email protected]> (cherry picked from commit 0ab6f07) Signed-off-by: Cory Snider <[email protected]>
Signed-off-by: Albin Kerouanton <[email protected]> (cherry picked from commit 8883db2) Signed-off-by: Rob Murray <[email protected]> (cherry picked from commit adfed82) Signed-off-by: Andrey Epifanov <[email protected]>
Backport the WithPortMap() function through a partial cherry-pick. Signed-off-by: Rob Murray <[email protected]> (cherry picked from commit 20c99e4) Signed-off-by: Andrey Epifanov <[email protected]>
Using iptables.OnReloaded to restore individual per-network rules on firewalld reload means rules for deleted networks pop back in to existence (because there was no way to delete the callbacks on network-delete). So, on firewalld reload, walk over current networks and ask them to restore their iptables rules. Signed-off-by: Rob Murray <[email protected]> (cherry picked from commit a527e5a) Test that firewalld reload doesn't re-create deleted iptables rules Signed-off-by: Rob Murray <[email protected]> (cherry picked from commit c3fa7c1) Signed-off-by: Andrey Epifanov <[email protected]>
On firewalld reload, all the iptables rules are deleted. Legacy links use iptables.OnReloaded to achieve that - but there's no way to deleted an OnRelaoded callback. So, a firewalld reload after the linked containers are deleted results in zombie rules being re-created. Legacy links are created by ProgramExternalConnectivity, but removed in Leave (rather than RevokeExternalConnectivity). So, restore legacy links for current endpoints, along with the other per-network/per-port rules. Move link-removal to RevokeExternalConnectivity, so that it happens with the configNetwork lock held. Signed-off-by: Rob Murray <[email protected]>
…eparate function Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 752758a) Signed-off-by: Andrey Epifanov <[email protected]>
Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 51ed289) Signed-off-by: Andrey Epifanov <[email protected]>
- Extract plumpIngressProxy steps in a separate function - Don't create a new listener if there's already one in ingressProxyTbl Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit c2e2e7f) Signed-off-by: Andrey Epifanov <[email protected]>
… improved rule management Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 19a8083) Signed-off-by: Andrey Epifanov <[email protected]>
…and Insert operations Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 262c325) Signed-off-by: Andrey Epifanov <[email protected]>
Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 4f0485e) Signed-off-by: Cory Snider <[email protected]>
…ing and initialization Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 50e6f4c) Signed-off-by: Andrey Epifanov <[email protected]>
… Del functions - refactor programIngressPorts to use Rule.Insert/Append/Delete for improved rule management - split programIngress() and dependent functions on Add and Del functions Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit 8b208f1) Signed-off-by: Andrey Epifanov <[email protected]>
Signed-off-by: Andrey Epifanov <[email protected]> (cherry picked from commit a1f68bf) Signed-off-by: Andrey Epifanov <[email protected]>
58b4443 to
f93d90c
Compare
Update advisory for GHSA-mh63-6h87-95cp The dependency causing this CVE, golang-jwt/jwt v3.2.1, is brought in via the project's main go.mod. Due to functional changes required to move away from v3 to v4/v5, upstream maintainers are required to do the necessary changes to the project code in order to fix this vulnerability. Update advisory for GHSA-4vq8-7jfc-9cvp This vulnerability affects Docker Engine (Moby) versions <= 25.0.12 where firewalld reload removes Docker''''s iptables rules that isolate containers in different bridge networks. Upstream maintainers must cut a release with the fix. References: 25.x backport PR: moby/moby#50445 28.x backport PR: moby/moby#50506' Update advisory for CVE-2024-36623 This vulnerability is being detected erroneously since this issue has been fixed since docker 25.0.4 and we currently ship v25.0.8 Signed-off-by: David Negreira <[email protected]>
Update advisory for GHSA-mh63-6h87-95cp The dependency causing this CVE, golang-jwt/jwt v3.2.1, is brought in via the project's main go.mod. Due to functional changes required to move away from v3 to v4/v5, upstream maintainers are required to do the necessary changes to the project code in order to fix this vulnerability. Update advisory for GHSA-4vq8-7jfc-9cvp This vulnerability affects Docker Engine (Moby) versions <= 25.0.12 where firewalld reload removes Docker''''s iptables rules that isolate containers in different bridge networks. Upstream maintainers must cut a release with the fix. References: 25.x backport PR: moby/moby#50445 28.x backport PR: moby/moby#50506' Update advisory for CVE-2024-36623 This vulnerability is being detected erroneously since this issue has been fixed since docker 25.0.4 and we currently ship v25.0.8
Update advisory for GHSA-mh63-6h87-95cp The dependency causing this CVE, golang-jwt/jwt v3.2.1, is brought in via the project's main go.mod. Due to functional changes required to move away from v3 to v4/v5, upstream maintainers are required to do the necessary changes to the project code in order to fix this vulnerability. Update advisory for GHSA-4vq8-7jfc-9cvp This vulnerability affects Docker Engine (Moby) versions <= 25.0.12 where firewalld reload removes Docker''''s iptables rules that isolate containers in different bridge networks. Upstream maintainers must cut a release with the fix. References: 25.x backport PR: moby/moby#50445 28.x backport PR: moby/moby#50506' Update advisory for CVE-2024-36623 This vulnerability is being detected erroneously since this issue has been fixed since docker 25.0.4 and we currently ship v25.0.8 Signed-off-by: David Negreira <[email protected]>
- What I did
On firewalld reload, all of Docker's iptables rules are removed. Docker notices the reload and restores the rules, with the exception that the Ingress rules for Docker Services in a Swarm mode are also not restored after firewalld reload and services become unreachable.
A further issue is that
iptables.OnReloadedis used to register callbacks to restore per-network and per-container rules on firewalld reload. That works fine ... but it continues working after the network/container has been deleted, because there's no way to un-register a callback. So, a firewalld reload is likely to lead to creation of zombie iptables rules.- How I did it
Restore iptables for current networks on firewalld reload
Using
iptables.OnReloadedto restore individual per-network rules on firewalld reload means rules for deleted networks pop back in to existence (because there was no way to delete the callbacks on network-delete).So, on firewalld reload, walk over current networks and ask them to restore their iptables rules.
Claim the
configNetworklock while doing that, and duringProgramExternalConnectivity/RevokeExternalConnectivity- to make sure there's no race between rules being deleted on network deletion (or default-gateway revocation), and restoring rules on firewalld reload.Restore legacy links along with other iptables rules
On firewalld reload, all the iptables rules are deleted. Legacy links use
iptables.OnReloadedto achieve that - but there's no way to delete anOnReloadedcallback. So, a firewalld reload after the linked containers are deleted results in zombie rules being re-created.Legacy links are created by
ProgramExternalConnectivity, but removed inLeave(rather thanRevokeExternalConnectivity).Restore ingress iptables rules in swarm mode
On firewalld reload, walk over current service binding and ask them to restore iptables.
So ...
configNetworklock held.- How to verify it
On a host running firewalld, with this in daemon.json ...
Create a couple of networks running a container each, and a couple of legacy-linked containers on the default bridge ...
Store the output of
iptables-saveandip6tables-save.Reload firewalld,
systemctl reload firewalld.Compare the output of
iptables-saveandip6tables-savewith the originals. The order of some rules may change, because rules for the networks/container are unlikely to be restored in the order they were originally created in. There shouldn't be any other differences.Check that the legacy-link still works.
Restore Ingress iptables rules on firewalld reload
In a swarm mode create a service:
Store the output of
iptables-saveandip6tables-save.Reload firewalld,
systemctl reload firewalld.Compare the output of
iptables-savewith the originals. The order of some rules may change, because rules for the networks/container are unlikely to be restored in the order they were originally created in. There shouldn't be any other differences.- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)