Dear Maintainer, * What led up to the situation? Any docker command like "docker images" * What was the outcome of this action? Network breaks for all libvirt VMs (i.e., they are not able to ping each other, or public domains, and after a reboot they do not get an IP via dhcp). The VMs are connected to a bridge (br0): # The loopback network interface auto lo iface lo inet loopback # The primary network interface #allow-hotplug eth2 #iface eth2 inet dhcp # This is an autoconfigured IPv6 interface #iface eth2 inet6 auto auto br0 iface br0 inet dhcp bridge_ports eth2 # bridge_stp on bridge_maxwait 0 bridge_fd 0 I don't have any firewall/iptables rules on my machine. * What outcome did you expect instead? That networking still works (as it did with older docker versions). The situation can be fixed via "iptables -I FORWARD -i br0 -o br0 -j ACCEPT". Before that I saw "Chain FORWARD (policy drop 3493 packests, 829K bytes)". Therefore, I assume that docker messages with the chains.
Control: tags -1 +moreinfo Which versions were working? It would be useful if you could provide a step by step set of instructions on how to reproduce this. For example, what type of VMs does libvirt use? KVM? How is docker configured? What commands are ran exactly? Thanks, A.
Hi,
docker is not configured in any special way, the only change to the
config file was attached in the original report.
Here are the relevant outputs of a full session after a fresh boot:
==== after boot ====
$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether c0:3f:d5:61:1a:0f brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether c0:3f:d5:61:1a:0f brd ff:ff:ff:ff:ff:ff
inet 10.43.70.1/16 brd 10.43.255.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2001:858:107:1:c23f:d5ff:fe61:1a0f/64 scope global mngtmpaddr dynamic
valid_lft 86398sec preferred_lft 14398sec
inet6 fe80::c23f:d5ff:fe61:1a0f/64 scope link
valid_lft forever preferred_lft forever
$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
$ brcrl show
bridge name bridge id STP enabled interfaces
br0 8002.c03fd5611a0f no eth2
==== after VM start (which is a KVM based VM, with its NIC on br0, device model virtio) ====
The output is from the host, the VM pings fine to public hostnames
(e.g., debian.org)
$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether c0:3f:d5:61:1a:0f brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether c0:3f:d5:61:1a:0f brd ff:ff:ff:ff:ff:ff
inet 10.43.70.1/16 brd 10.43.255.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2001:858:107:1:c23f:d5ff:fe61:1a0f/64 scope global mngtmpaddr dynamic
valid_lft 86394sec preferred_lft 14394sec
inet6 fe80::c23f:d5ff:fe61:1a0f/64 scope link
valid_lft forever preferred_lft forever
4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:67:36:c8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe67:36c8/64 scope link
valid_lft forever preferred_lft forever
$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.c03fd5611a0f no eth2
vnet0
==== after "docker images" (yes, the only docker command I ran), and from this point on networking in the VM is dead: ====
$ ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
link/ether c0:3f:d5:61:1a:0f brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether c0:3f:d5:61:1a:0f brd ff:ff:ff:ff:ff:ff
inet 10.43.70.1/16 brd 10.43.255.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2001:858:107:1:c23f:d5ff:fe61:1a0f/64 scope global mngtmpaddr dynamic
valid_lft 86397sec preferred_lft 14397sec
inet6 fe80::c23f:d5ff:fe61:1a0f/64 scope link
valid_lft forever preferred_lft forever
4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:67:36:c8 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe67:36c8/64 scope link
valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:52:94:20:6b brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever
$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-ISOLATION all -- anywhere anywhere
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
Chain DOCKER-ISOLATION (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.c03fd5611a0f no eth2
vnet0
docker0 8000.02425294206b no
The FORWARD chain policy is set to DROP by docker since 1.13.
The verbose (-V) iptables output (which gives interfaces and packet counters) is:
# iptables -L -v -n
Chain INPUT (policy ACCEPT 281 packets, 14176 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER-ISOLATION all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 225 packets, 27980 bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
Chain DOCKER-ISOLATION (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
I reproduced the network setup but not the KVM one.I cannot confirm
that forwarding is broken.
Upstream provides:
- a command line switch to docker daemon "--iptables=false"
or a config item in /etc/docker/daemon.json:
{
"iptables": false
}
- upstream also tell to revert the FORWARD policy to ACCEPT byhand ...
but I tested and it stay so on docker restart (even stop and start).
If the box is rebooted the change is lost
as confirmed by https://docs.docker.com/engine/userguide/networking/default_network/container-communication/
"The iptables settings are lost when the system reboots. If you want the change to be permanent,
refer to your Linux distribution’s documentation."
Mind we cannot apply it from /etc/rc.local or anything boot related as it has to be applied
after docker is started ...
with socket activation we activate docker daemon long after boot.
references:
- https://docs.docker.com/engine/userguide/networking/default_network/container-communication/
Container communication between hosts
For security reasons, Docker configures the iptables rules to prevent containers from forwarding traffic
from outside the host machine, on Linux hosts. Docker sets the default policy of the FORWARD chain to DROP.
(...)
Note: In Docker 1.12 and earlier, the default FORWARD chain policy was ACCEPT. When you upgrade
to Docker 1.13 or higher, this default is automatically changed for you.
- Also from https://docs.docker.com/engine/userguide/networking/default_network/container-communication/
Communication between containers
(...)
Docker will never make changes to your system iptables rules if you set --iptables=false when the daemon starts.
Otherwise the Docker server will add a default rule to the FORWARD chain with a blanket ACCEPT policy
if you retain the default --icc=true, or else will set the policy to DROP if --icc=false.
Best regards
Alban
Seems like the docker.io package should ship this as a conffile then.
I'm lowering severity of this bug since it is not clear how to reproduce the problem and because networking is not broken for everyone...
* Alban Browaeys <prahal@yahoo.com> [171022 00:01]: HUH??? Since when is it okay for software that is not advertised as firewall software to modify the sysadmin's implicit or explicit iptables setup for IP packets completely unrelated to said software? I understand that this is a non-trivial problem because of the history behind /proc/sys/net/ipv4/ip_forward and the FORWARD chain, but docker can and needs to do better. My first approximation would be to only change the policy for FORWARD if ip_forward was 0 before docker added its own iptables rules. This will probably work 99.9% of the time. The current behavior appears to break other software 100% of the time if that software relies on ip_forward being 1 and the FORWARD chain being in its default state. * Dmitry Smirnov <onlyjob@debian.org> [180607 09:31]: system break), as I cannot fathom how this could not be broken for anyone using KVM with a bridging network interface unless they have found one of the workarounds given in this thread (i.e. the /etc/docker/daemon.json modification, or manually modifying the FORWARD chain). The following should reliably reproduce the problem (disclaimer: I haven't gone back to a clean system and tried this from the start, but I have been using virt-manager for a while, and installing docker.io immediately broke networking on my VMs): * Ensure dockerd is not running and iptables is empty and in its default state (FORWARD chain policy is ACCEPT). * Install virt-manager. * Create a virtual machine with a bridging virtual network interface (e.g. for network source choose "Bridge br0: Host device ens3" where ens3 is the host's wired interface to the LAN). * Ensure networking on the VM works correctly (to the LAN or beyond), and that FORWARD chain still has POLICY ACCEPT. * Start dockerd. The VM's networking to the LAN or beyond (but not to the host machine) will now be broken. Another scenario that I expect to reliably fail is machine A with two wired NIC's, one connected to the LAN and the other connected directly to isolated machine B (e.g. a Raspberry Pi). The connection between A and B could be USB networking. Ensure: * The LAN gateway has a route to B via A. (Using a different /24 between A and B is recommended here.) * Machine A has ip_forward set to 1, and empty, default FORWARD chain. * Machine A has a route to B. * Machine B can reach outside the LAN. I would be extremely surprised if installing docker.io did not break this scenario for machine B. ...Marvin
This bug is basically a duplicate of #903635. Situation is unfortunate and upstream does not care enough. They probably want Docker users to use Docker exclusively without any other software on the host. I very much dislike this approach but that's Docker for you... :( About 6 months ago I've moved all my application containers from Docker to "rkt" and I couldn't be happier. Although still immature, in the future libpod/podman will likely become a worthy Docker successor. I'm lowering severity back to "important". You are not wrong that Docker is hostile to other applications but I think many users would agree that we need Docker in "testing" and upcoming Debian release despite of this problem.--- Truth never damages a cause that is just. -- Mahatma Gandhi
[I'm subscribed to this bug, you don't need to include me in TO or CC.]
* Dmitry Smirnov <onlyjob@debian.org> [181126 20:45]:
Not really. Bug #903635 is about not obeying a documented command line
option. This bug is about incorrectly modifying iptables when it is
enabled. I.e. when --iptables=true, the modification is done is wrong
(in a way that breaks networking configuration for non-docker software).
I appreciate your candor regarding upstream's attitude.
Would you mind forwarding this upstream anyway, to give them the
opportunity to do the right thing? Here is my suggestion to them to fix
this bug:
1. Only change the FORWARD chain policy if ip_forward was 0 before
adding rules to this chain (obviously docker sets ip_forward to 1 if
it wasn't already).
2. Only add two rules to FORWARD:
-A FORWARD -o docker0 -j DOCKER-IN
-A FORWARD -i docker0 -j DOCKER-OUT
Add all other rules to docker-specific chains (DOCKER-IN and -OUT can
jump to DOCKER-USER and -ISOLATION-* as desired). This ensures that
only docker-related packets make it to the docker chains, so the docker
chains cannot modify non-docker packets.
This has the advantage that you don't need to keep testing -i docker0 or
-o docker0 on multiple rules, making the filtering more efficient.
Thanks for this tip; I'll investigate.
Okay. I understand and agree that the current situation is better than
not having docker in the archive. Since this has the potential to break
other software on initial installation or upgrade from an older version,
can you put an item in NEWS.Debian pointing to this bug and mentioning
the /etc/docker/daemon.json workaround?
Thanks for your work packaging docker!
...Marvin
Please note that this is introduced by upstream in https://github.com/docker/docker/pull/28257
Resent..
severity 865975 critical thanks My report just got merged into this one as a duplicate, so sorry for being late to the party… the severity. I agree that we should ship Docker in Buster, even if we have not resolved this issue in time, since we couldn't introduce it after the fact, and it's an important and/or high-profile package. But the bug clearly meets the criteria for Critical severity: "makes unrelated software on the system (or the whole system) break": one can witness unrelated VMs lose networking in real time by starting the docker daemon and triggering the policy change. The proper way to try and ensure that Docker does not get dropped from Buster is to either fix the bug or request an exception from the release team (a "buster-ignore" tag). Lowering the severity to avoid triggering a removal is just hiding the bug from RC bug summaries and dashboards etc., violating SC §3 "We will not hide problems". I'm fairly confident that the release team would tag this buster-ignore. But, the preferred solution is, of course, to fix the bug. As Clint points out in [1], a solution is to ship a minimal conffile. On the face of it that seems like a simple solution, which has not been discussed by anyone else yet in the bug. I've tested the concept and it works, but needs cooking up into a patch. What are the caveats for this? At a minimum we would need a README.Debian too, I guess. [1] <20180104025648.eycf37gbzkxe7usq@scru.org>
Hi, I checked more carefully on https://github.com/moby/moby/pull/28257 and https://github.com/moby/moby/issues/14041 Then I concluded that docker does nothing wrong in this case. If you didn't set net.ipv4.ip_forward=1 before starting docker, then docker will set this for you by default, otherwise the containers can't access the network. This causes security issue as described in https://github.com/moby/moby/issues/14041. So if docker set net.ipv4.ip_forward=1 itself, it will set the default FORWARD policy to DROP. This looks quite correct. So when docker will not touch your FORWARD policy? just don't let docker enable ip_forward itself. You can set net.ipv4.ip_forward=1 in /etc/sysctl.conf(enable it before starting docker). Then docker will know that user want the host to forward all traffic and it will touch your default FORWARD policy. I've verified it by adding net.ipv4.ip_forward=1 to /etc/sysctl.conf, then reboot. And my FORWARD policy is ACCEPT. So as for your VM scenario, why didn't you set ip_forward manually? How docker know it's not a vulnerability if it didn't set FORWARD chain to DROP when it enables ip_forward.
Control: severity -1 normal [...] With the reason I explained last week, I would downgrade this issue. Arnaud, when you upload new version for the CVE issue, could you amend the README.Debian to tell people that if they don't want docker to set default FORWARD policy to DROP, they should enable ip_forward intentionally. (I bet your english is better than me to draft a phrase...)
Hi, I will, and can even go further and display an explicit message when user upgrade the package maybe? (I'm not sure how to do that but I'm sure I'll find an example easily). I'm quite busy now but I hope I'll have time before the end of the week to do all of that. Thanks,
docker.io already has a NEWS file, you can just add a new entry, by running: dch --news debian/docker.io.NEWS but I don't think it's needed... docker.io is not in stretch, so people will not upgrade it from stretch. And this issue exists since 1.13.0(long ago).
That, in particular I think is a bad idea. It seems like it might be useful when you consider one package in isolation, but then upgrades become really painful when a whole load of such packages all have their messages one after the other.
Sorry for not replying sooner, I had a very busy week.
Your code review and conclusions from it are reasonable. I read them
last week (although I did not have time to reply) and my thoughts were:
is that the code in the current Debian package?
I ask because the reason I filed this in the first place is because I
hit it on my main Debian system. My kvm/libvirt-based VMs lost their
networking due to docker changing the forward iptables policy. I had
not manually modified the ip_forward /proc setting, so either
1) this was not necessary for libvirt/kvm's networking to function,
and so is not a perfect test as to whether changing the forwarding
iptables chain will break something
or
2) libvirt/kvm's networking set the ip_forward proc setting it required,
and the packaged docker does not correctly check the proc value before
making the change, despite the logic in the code linked above (or
perhaps that is not the code corresponding to the docker version that
is presently packaged)
(Or I suppose 3), a race is possible between the /proc check and the iptables
change, but I don't think that's likely what has happened in my case.)
So IMHO the severity drop is not appropriate because it's predicated on a
theoretical reasoning of the situation rather than a practical one, i.e., I
actually hit this on a real machine in real circumstances. But I will attempt
to reproduce it a second time on my real machine before challenging the
severity again.
To respond to some of your specific points:
Because I did not need to. Either it was not necessary for the specific
networking setup for my libvirt/kvm VMs, or libvirt/kvm set it explicitly
itself. I do not manually need to tweak stuff in /proc. As part of
reproducing this I will check the specific network setup that the libvirt
VMs are using, but it's the package/debian default.
They could add a "-j DROP" rule that was scoped specifically to the docker
subnet, after their other (-j ACCEPT) rules. That's just one way that this
could be done less disruptively.
Yes, you can check it here https://sources.debian.org/src/docker.io/18.09.1+dfsg1-7/libnetwork/drivers/bridge/setup_ip_forwarding.go/#L31 The code is only called if ip_forward is not enabled. Please do think more about this issue. And understand why docker does this for the security reason. Because libvirt enables ip_forward itself. https://sources.debian.org/src/libvirt/5.0.0-3/src/network/bridge_driver.c/#L2207 And I would argue this is a security issue too, if libvirt enables ip_forward and does nothing else. No, because they enabled ip_forward setting.
I understand the security issue. I understand why it does it. But if its the case that this does break unrelated software, i.e., if the ip_forward check is not sufficient/is not working (I am still to retest), then we also have that problem. And it's not clear which is "worse". I agree. Sure, but using a -j DROP rule means it's at least theoretically possible for unrelated software to have its own rules in the forward chain that are not broken by the chain policy change. Having said that, I'm only sketching the outline of an alternative solution here; it would need working up into a proper alternative solution, and I do not have the time to do that.
Hi Shengjing Zhu (et al) I've just (finally) attempted to reproduce this on my Buster host, but could not on this attempt. Libvirtd did not change my ip_forward setting from 0 to 1 in the test, but I had to do so manually to re-enable VM networking outside of the host (I don't think I did this manually in the first instance). Docker did not change the FORWARD chain policy since ip_forward was set to 1. My libvirtd VMs are using the default bridged network. I'll keep trying to reproduce this but for now let's assume that it doesn't happen.
Regretfully, this bug is still active and it's trivial to reproduce with this configuration: * apt-get install docker.io (ensure that the docker daemon is running afterwards. Tested with 20.10.22+dfsg1-2 locally) * apt-get install lxd (tested with 5.0.1-5) Then, "lxc launch ubuntu:22.04" (accepting the defaults for LXD configuration). Networking will be broken inside the newly created LXD container. The workaround for me is to run "sudo iptables -P FORWARD ACCEPT" after bootup (and after Docker has started). But I agree with previous comments; it's EXTREMELY BAD and unacceptable for a program like Docker to misbehave like this. On the LXD side, this has been discussed and is a known issue: * https://discuss.linuxcontainers.org/t/lxd-and-docker-firewall-redux-how-to-deal-with-forward-policy-set-to-drop/9953/9 * https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_firewalld/#prevent-issues-with-lxd-and-docker (The suggestion given there is to insert firewall rules into the DOCKER-USER chain.) I suggest we would consider patching the Docker package in Debian to remove the FORWARD DROP nonsense until this has been properly resolved upstream. We can't have programs that misbehave this badly in the distribution, IMO. Best regards, Per Lundberg
Please read message#91 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91 and then think about it. If you still think there's a secure patch that we can apply, I'd like to review.
Hi Shengjing Zhu, Hmm, you have some very valid points and concerns there. I should have read the whole bug before commenting... :-) What surprises me though is that on Ubuntu, this seemingly works correctly (presuming that LXD is running as a snap in that case), as pointed out by a colleague. I don't know why but it would be interesting to dig deeper into the details here. I asked my colleague to check his sysctl settings and they look identical to mine (IPv4 forwarding not enabled in /etc/sysctl.conf). This is from his Ubuntu 22.04 machine: user@host:~$ grep net.ipv4.ip_forward /etc/sysctl.conf #net.ipv4.ip_forward=1 user@host:~$ sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 user@host:~$ grep ip_forward /etc/sysctl.d/* /etc/sysctl.d/99-sysctl.conf:#net.ipv4.ip_forward=1 I'm almost inclined to set up an Ubuntu VM to test this in, but I don't really have the time (at work) right now. If anyone reading this has more insight into this, it would be incredibly interesting. Best regards, Per
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Installation of debian testing in Virtual Box (windows 10 Host) and basic use of docker.io
* What exactly did you do (or not do) that was effective (or
ineffective)?
Creation of a VM in Virtual Box, no customization at all
Installation of debian testing in this VM, no customization at all
Installation of docker.io
Open a terminal and execute command "ping google.fr"
=> ping is OK for hours
In another terminal execute "docker run -dit -p 8080:80 -v "$PWD":/usr/local/apache2/htdocs/ httpd:2.4
After a few seconds (10 - 40s) the ping command displays "Destination Host Unreachable"
docket stop <containerID> resolves the problem and ping command immediatly reaches destination
applying iptables commands mentionned above doesn't solve the problem
configuring docker like this
/etc/docker/daemon.json:
{
"iptables": false
}
prevents docker from modifying iptables config but doesn't solve the problem
* What was the outcome of this action?
Systematically, VM access to internet is broken
* What outcome did you expect instead?
Same behaviour as in Debian stable, no network broken access
This nominal usage of docker works in ubuntu 22.10 installed today for this test
*** End of the template - remove these template lines ***
Dear Maintainer,
I come here with a different use-case. I use Debian on a desktop, in a
room where the home wifi is weak. The desktop is connected by wire,
but also has a wireless network adapter, so I set up a hotspot for my
phone -- using tools from KDE (plasma-nm). I never touched the kernel
configuration or firewall rules, as (like Jonathan above) I never
needed to.
Recently I installed Docker in order to play with something, and it
took me quite a while to find out why, suddenly, when my phone
connects to the hotspot, it gets no access to the internet.
Docker's "solution" of only blocking forwarding if it set
ip_forwarding=1 itself is not helpful in my case -- the hotspot was
defined in my desktop, but the docker daemon starts at boot, typically
before I can log in.
When the access point is active, the following nft rules are set:
table ip nm-shared-wlan0 {
chain nat_postrouting {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 10.42.0.0/24 ip daddr != 10.42.0.0/24 masquerade
}
chain filter_forward {
type filter hook forward priority filter; policy accept;
ip daddr 10.42.0.0/24 oifname "wlan0" ct state { established, related } accept
ip saddr 10.42.0.0/24 iifname "wlan0" accept
iifname "wlan0" oifname "wlan0" accept
iifname "wlan0" reject
oifname "wlan0" reject
}
}
This makes sense to me; when the UI opens up forwarding, it sets up
firewall rules to protect its own interfaces. Not everyone
else's. This is in the spirit of what Marvin suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#53 -- and it
makes me disagree with the statement in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91, that
Docker is "doing nothing wrong".
I should point also that in the original issue, the main motivation
behind seeing this as a security issue is to protect the containers
(see
e.g. https://github.com/moby/moby/issues/14041#issuecomment-113554682).
I realize that opening up forwarding can affect the security of a
system. I think that Debian should ship a docker package which
doesn't do this (this seems to be controllable by configutation), but
instead, makes the proper changes to the system upon installation (and
lets the user know).
(the option to just error out from Docker if forwarding is not set up
was also mentioned on the ticket).
Also, since I'm not convinced by the argument in message #91, and
since I've had docker break unrelated functionality, I also disagree
with the downgrade in message #98. This behavior, as has not been
contested, "makes unrelated software on the system break". I agree
that before the behavior's introduction, it "introduce[d] a security
hole on systems where you install[ed] the package", which is also
critical, but that should not make it acceptable to break unrelated
software.