CODEWITHSUNDEEP
permissionsdocker
Andrew Beresford
Andrew Beresford

Reputation: 566

Docker - non-privileged user can write to / inside container

I've created a container, based off the centos:6.8 image using the following Dockerfile:

FROM centos:6.8
RUN adduser -m test
USER test

The image is then built using docker build:

docker build -t dockerdemo .

Then I start a container with:

docker run -ti dockerdemo bash

When I am inside the container, I appear to be able to write as the "test" user into the root directory of the container:

[test@9af9c4aeb990 /]$ ls -ld /
drwxr-xr-x 29 root root 4096 Oct 25 09:49 /
[test@9af9c4aeb990 /]$ id -a
uid=500(test) gid=500(test) groups=500(test)
[test@9af9c4aeb990 /]$ touch /test-file
[test@9af9c4aeb990 /]$ ls -l /test-file
-rw-rw-r-- 1 test test 0 Oct 25 09:49 /test-file

I am expecting to see Permission denied when I run the touch command.

If I alter the Dockerfile and remove the USER statement, and rebuild, then I can su to the "test" user inside the container and I get the behaviour I would expect:

[root@d16277f693d8 /]# su - test
[test@d16277f693d8 ~]$ id      
uid=500(test) gid=500(test) groups=500(test)
[test@d16277f693d8 ~]$ ls -ld /    
drwxr-xr-x 29 root root 4096 Oct 25 09:50 /
[test@d16277f693d8 ~]$ touch /test-file
touch: cannot touch `/test-file': Permission denied

Have I misunderstood how user permissions work inside containers?

Is there a way to produce my expected behaviour?

Upvotes: 1

Views: 281

Answers (1)

BMitch
BMitch

Reputation: 264236

There was a vulnerability announced in 1.12.2 that your scenario matches. Release 1.12.3 just came out yesterday to fix this issue and CVE-2016-8867 was registered on the vulnerability. It's an internal container privilege escalation, so limited impact, but still worth the upgrade.

Upvotes: 1

Related Questions