Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@corhere
Copy link
Contributor

@corhere corhere commented Jul 17, 2025

- 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.OnReloaded is 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.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.

Claim the configNetwork lock while doing that, and during ProgramExternalConnectivity / 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.OnReloaded to achieve that - but there's no way to delete an OnReloaded 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).

Restore ingress iptables rules in swarm mode

On firewalld reload, walk over current service binding and ask them to restore iptables.

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.

- How to verify it

On a host running firewalld, with this in daemon.json ...

        "icc": false,
        "ipv6": true,
        "fixed-cidr-v6": "fddd::/64",

Create a couple of networks running a container each, and a couple of legacy-linked containers on the default bridge ...

docker network create --ipv6 n1
docker network create --ipv6 n2
docker run -d --rm --network n1 nginx
docker run -d --rm --network n2 alpine
docker run --rm -d -ti -p 8080:80 --name nginx nginx
docker run --rm -ti --link nginx alpine

Store the output of iptables-save and ip6tables-save.

Reload firewalld, systemctl reload firewalld.

Compare the output of iptables-save and ip6tables-save with 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:

docker swarm init
docker network create -d overlay n0
docker service create --name nginx --publish target=80,published=80 --replicas=1 --network n0 nginx

Store the output of iptables-save and ip6tables-save.

Reload firewalld, systemctl reload firewalld.

Compare the output of iptables-save with 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

- Prevent restoration of iptables rules for deleted networks and containers on firewalld reload.
- Fix Swarm services becoming unreachable from published ports after a firewalld reload.

- A picture of a cute animal (not mandatory but encouraged)

@akerouanton
Copy link
Member

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.

@robmry
Copy link
Contributor

robmry commented Jul 24, 2025

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 firewall-cmd --state doesn't report running.

It passes in test (graphdriver) / integration (ubuntu-24.04, firewalld).

@corhere corhere force-pushed the backport-25.0/fix-firewalld-reload branch from 70a1d42 to 58b4443 Compare July 24, 2025 16:24
robmry and others added 14 commits July 25, 2025 14:46
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]>
@corhere corhere force-pushed the backport-25.0/fix-firewalld-reload branch from 58b4443 to f93d90c Compare July 25, 2025 19:17
@corhere corhere merged commit a43c1ee into moby:25.0 Jul 28, 2025
133 of 134 checks passed
@corhere corhere deleted the backport-25.0/fix-firewalld-reload branch July 28, 2025 16:06
dnegreira added a commit to dnegreira/advisories that referenced this pull request Sep 2, 2025
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]>
dnegreira added a commit to dnegreira/advisories that referenced this pull request Sep 2, 2025
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
github-merge-queue bot pushed a commit to wolfi-dev/advisories that referenced this pull request Sep 2, 2025
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants