Package: docker.io
Followup-For: Bug #865975
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.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (800, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages docker.io depends on:
ii adduser 3.137
pn containerd <none>
ii init-system-helpers 1.65.2
ii iptables 1.8.9-2
ii libc6 2.37-7
ii libdevmapper1.02.1 2:1.02.185-2
ii libsystemd0 254.1-2
ii lsb-base 11.6
pn runc <none>
ii sysvinit-utils [lsb-base] 3.07-1
pn tini <none>
Versions of packages docker.io recommends:
ii apparmor 3.0.12-1
ii ca-certificates 20230311
pn cgroupfs-mount <none>
ii git 1:2.40.1-1
ii needrestart 3.6-5
ii xz-utils 5.4.4-0.1
Versions of packages docker.io suggests:
pn aufs-tools <none>
pn btrfs-progs <none>
pn debootstrap <none>
pn docker-doc <none>
ii e2fsprogs 1.47.0-2
pn rinse <none>
pn rootlesskit <none>
pn xfsprogs <none>
pn zfs-fuse | zfsutils-linux <none>
