Networking/Security: Custom net with both --internal and --icc=false does not block icc

[diekmann]

Description

I create a network which should be internal and inter-container communication (icc) should also be prohibited. However, icc is allowed.

Steps to reproduce the issue:

1. docker network create -d bridge --subnet=192.168.10.0/24 --opt="com.docker.network.bridge.enable_icc=False" --internal mynetint
2. Inspect iptables-save, docker does not install rules to prevent icc

Describe the results you received:

Docker installs the following additional iptables rules when I enter the command above (diff):

+-A DOCKER-ISOLATION ! -s 192.168.10.0/24 -o br-9d9f7fff544d -j DROP
+-A DOCKER-ISOLATION ! -d 192.168.10.0/24 -i br-9d9f7fff544d -j DROP

This only makes the network internal. Docker installs the very same rules if I leave out the --opt="com.docker.network.bridge.enable_icc=False" option (or use lower-case false).

Describe the results you expected:

If I just run docker network create -d bridge --subnet=192.168.10.0/24 --opt="com.docker.network.bridge.enable_icc=False" mynetint without --internal, docker adds the following iptables rules (diff):

 -A FORWARD -j DOCKER-ISOLATION
+-A FORWARD -o br-2f4e24d5565f -j DOCKER
+-A FORWARD -o br-2f4e24d5565f -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
+-A FORWARD -i br-2f4e24d5565f ! -o br-2f4e24d5565f -j ACCEPT
 -A FORWARD -o docker0 -j DOCKER
 -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 -A FORWARD -i docker0 ! -o docker0 -j ACCEPT
 -A FORWARD -i docker0 -o docker0 -j ACCEPT
+-A FORWARD -i br-2f4e24d5565f -o br-2f4e24d5565f -j DROP
+-A DOCKER-ISOLATION -i docker0 -o br-2f4e24d5565f -j DROP
+-A DOCKER-ISOLATION -i br-2f4e24d5565f -o docker0 -j DROP
 -A DOCKER-ISOLATION -j RETURN

In particular, note the rule -A FORWARD -i br-2f4e24d5565f -o br-2f4e24d5565f -j DROP which drops icc. This rule is missing if I add the --internal command when I create the network.

My expectation: I get a network which is both internal and icc is prevented. This may be important for security.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 22:01:48 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 22:01:48 2016
 OS/Arch:      linux/amd64

Output of docker info:

Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 4
Server Version: 1.12.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 19
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.4.0-51-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.954 GiB
Name: corny-VirtualBox
ID: 3LQY:RGTD:USVY:3GKG:XJLW:CQ6U:FY6O:DBYK:LG25:LQVB:RYWD:VPAL
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Environment: Testing docker in lubuntu16.04 virtual machine on VirtualBox.

[aboch]

This was first reported in #26724. The fix is already in master and will be available in docker 1.13.x

[diekmann]

Thanks, there we have the merged fix: moby/libnetwork#1525

Will the fix be backported and distributed as security update for my docker version?

[thaJeztah]

Will the fix be backported and distributed as security update for my docker version?

@aboch perhaps you could have a look at that possibility; I don't know if it's gonna be a breaking change

[aboch]

@thaJeztah The fix is not a breaking change. We did not included in the 1.12.x cherry-pick because the issue existed in 1.11.x, not a breakage introduced in 1.12.x. We did not think of it as a security issue though.

@mavenugo Based on @diekmann 's view of this as a security issue, I think we should consider back porting the fix to 1.12.x branch. It is also a simple one. WDYT ?

[aboch]

Fix ported to 1.12.x by #29146