Description
Docker 1.12.2 does not correctly apply user permissions in containers.
Steps to reproduce the issue:
- Create a Dockerfile as follows:
FROM debian
RUN useradd example
RUN id
USER example
RUN id
RUN cat /etc/shadow
CMD /bin/bash
- docker build --no-cache -t example .
Sending build context to Docker daemon 155.1 MB
Step 1 : FROM debian
---> ddf73f48a05d
Step 2 : RUN useradd example
---> Running in 1791589193df
---> 8b03b79855a4
Removing intermediate container 1791589193df
Step 3 : RUN id
---> Running in b2ff8d1cad96
uid=0(root) gid=0(root) groups=0(root)
---> 3a17be9d5e6f
Removing intermediate container b2ff8d1cad96
Step 4 : USER example
---> Running in 7d07637c4492
---> 946266261780
Removing intermediate container 7d07637c4492
Step 5 : RUN id
---> Running in 22ae65564b94
uid=1000(example) gid=1000(example) groups=1000(example)
---> 6486bfff2351
Removing intermediate container 22ae65564b94
Step 6 : RUN cat /etc/shadow
---> Running in 545e009f4250
root:*:17067:0:99999:7:::
daemon:*:17067:0:99999:7:::
bin:*:17067:0:99999:7:::
sys:*:17067:0:99999:7:::
sync:*:17067:0:99999:7:::
games:*:17067:0:99999:7:::
man:*:17067:0:99999:7:::
lp:*:17067:0:99999:7:::
mail:*:17067:0:99999:7:::
news:*:17067:0:99999:7:::
uucp:*:17067:0:99999:7:::
proxy:*:17067:0:99999:7:::
www-data:*:17067:0:99999:7:::
backup:*:17067:0:99999:7:::
list:*:17067:0:99999:7:::
irc:*:17067:0:99999:7:::
gnats:*:17067:0:99999:7:::
nobody:*:17067:0:99999:7:::
systemd-timesync:*:17067:0:99999:7:::
systemd-network:*:17067:0:99999:7:::
systemd-resolve:*:17067:0:99999:7:::
systemd-bus-proxy:*:17067:0:99999:7:::
example:!:17094:0:99999:7:::
---> a20eb2ad353a
Removing intermediate container 545e009f4250
Step 7 : CMD /bin/bash
---> Running in 3bc78e8b7617
---> 7cd3b55873c7
Removing intermediate container 3bc78e8b7617
Successfully built 7cd3b55873c7
- docker run -u example -it example
example@2fdde3bace94:/$ id
uid=1000(example) gid=1000(example) groups=1000(example)
example@2fdde3bace94:/$ whoami
example
example@2fdde3bace94:/$ chmod +s /bin/sh
example@2fdde3bace94:/$ /bin/sh
# whoami
root
#
Describe the results you received:
When a non privileged user is defined in the Dockerfile, the container, as expected, starts as a non privileged user. Even if a non-privileged user is enforced, privileged commands can be executed.
This behavior only happens with Docker version 1.12.2, build bb80604 and and has been tested both with and without setting the -u modifier.
I have also tested Docker 1.12.1 and this issue does not occur:
docker build -t newversion . --no-cache
Sending build context to Docker daemon 155.1 MB
Step 1 : FROM registry.access.redhat.com/rhel7.2:latest
---> 98a88a8b722a
Step 2 : RUN useradd example
---> Running in a634c08405f8
---> 060c945c7f30
Removing intermediate container a634c08405f8
Step 3 : RUN id
---> Running in 8aaad2d0cabe
uid=0(root) gid=0(root) groups=0(root)
---> 599f75c31f64
Removing intermediate container 8aaad2d0cabe
Step 4 : USER example
---> Running in 97356bf6dc19
---> 9d57a913b64a
Removing intermediate container 97356bf6dc19
Step 5 : RUN id
---> Running in 5d49b3a7c03d
uid=1000(example) gid=1000(example) groups=1000(example)
---> fd1effd96c25
Removing intermediate container 5d49b3a7c03d
Step 6 : RUN cat /etc/shadow
---> Running in 42539688c8c1
cat: /etc/shadow: Permission denied
The command '/bin/sh -c cat /etc/shadow' returned a non-zero code: 1
docker -v
Docker version 1.12.1, build 23cf638
The issue is reproducible with various image defined in FROM : alpine, centos, rhel, debian...
Describe the results you expected:
Non privileged users inside containers should not be able to access privileged system functions. The following actions were possible as a non privileged user:
- Write to /
- Read and write to /etc/shadow
- Add SUID to sh
- Add users to the system
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version:
Client:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built: Tue Oct 11 17:53:36 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built: Tue Oct 11 17:53:36 2016
OS/Arch: linux/amd64
Output of docker info:
Containers: 191
Running: 2
Paused: 0
Stopped: 189
Images: 56
Server Version: 1.12.2
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 591
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: host null bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 4.5.0-kali1-amd64
Operating System: Kali GNU/Linux Rolling
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.37 GiB
Name: Omega
ID: 3W4I:EJTU:52I3:PUB3:VS3R:UVZ7:PRLI:GE4D:A7TL:IQGA:Q3DO:V5V7
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: *****
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
Insecure Registries:
127.0.0.0/8
Additional environment details (AWS, VirtualBox, physical, etc.):
Tested on Kali Linux, Fedora and Ubuntu LTS
Description
Docker 1.12.2 does not correctly apply user permissions in containers.
Steps to reproduce the issue:
Describe the results you received:
When a non privileged user is defined in the Dockerfile, the container, as expected, starts as a non privileged user. Even if a non-privileged user is enforced, privileged commands can be executed.
This behavior only happens with Docker version 1.12.2, build bb80604 and and has been tested both with and without setting the -u modifier.
I have also tested Docker 1.12.1 and this issue does not occur:
The issue is reproducible with various image defined in FROM : alpine, centos, rhel, debian...
Describe the results you expected:
Non privileged users inside containers should not be able to access privileged system functions. The following actions were possible as a non privileged user:
Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):
Tested on Kali Linux, Fedora and Ubuntu LTS