Docker Community Forums

Share and learn in the Docker community.

[SELinux] No longer able to access /dev in containers after docker-engine 1.11 on CentOS 7


(Dev) #1

Just updated docker on my CentOS 7 server to version 1.11 from 1.10.x and my containers will no longer start. They are getting permission denied when trying to open /dev/null

The issue is that the /dev mount inside the container appears to be labeled as docker_tmpfs_t and the context the container run in (svirt_lxc_net_t) is not allowed to access resources with that label.

I can work around this by patching my local SELinux policy directly, but this feels like a bug to me.

Any thoughts?


(Keithroberts) #2

https://docs.docker.com/engine/userguide/containers/dockervolumes/

Volume labels

Labeling systems like SELinux require that proper labels are placed on volume
content mounted into a container. Without a label, the security system might
prevent the processes running inside the container from using the content. By
default, Docker does not change the labels set by the OS.

To change a label in the container context, you can add either of two suffixes
:z or :Z to the volume mount. These suffixes tell Docker to relabel file
objects on the shared volumes. The z option tells Docker that two containers
share the volume content. As a result, Docker labels the content with a shared
content label. Shared volume labels allow all containers to read/write content.
The Z option tells Docker to label the content with a private unshared label.
Only the current container can use a private volume.

HTH


(Dev) #3

@keithroberts

Thanks for the reply, however /dev is not a docker volume.

To demonstrate the issue, below is what I get when list the /dev directory inside a container created from the centos:7 image.

The invocation is as follows

docker run --rm centos:7 ls -laZ /dev

The result is.

 drwxr-xr-x. root root system_u:object_r:docker_tmpfs_t:s0 .
 drwxr-xr-x. root root system_u:object_r:svirt_sandbox_file_t:s0:c3,c951 ..
 lrwxrwxrwx. root root system_u:object_r:docker_tmpfs_t:s0 core -> /proc/kcore
 lrwxrwxrwx. root root system_u:object_r:docker_tmpfs_t:s0 fd -> /proc/self/fd
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 full
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 fuse
 drwxrwxrwt. root root system_u:object_r:docker_tmpfs_t:s0 mqueue
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 null
 lrwxrwxrwx. root root system_u:object_r:docker_tmpfs_t:s0 ptmx -> pts/ptmx
 drwxr-xr-x. root root system_u:object_r:devpts_t:s0    pts
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 random
 drwxrwxrwt. root root system_u:object_r:svirt_sandbox_file_t:s0:c3,c951 shm
 lrwxrwxrwx. root root system_u:object_r:docker_tmpfs_t:s0 stderr -> /proc/self/fd/2
 lrwxrwxrwx. root root system_u:object_r:docker_tmpfs_t:s0 stdin -> /proc/self/fd/0
 lrwxrwxrwx. root root system_u:object_r:docker_tmpfs_t:s0 stdout -> /proc/self/fd/1
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 tty
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 urandom
 crw-rw-rw-. root root system_u:object_r:docker_tmpfs_t:s0 zero

Notice that the current directory ‘.’ is labeled as docker_tmpfs_t as are most of the relevant device files and links zero, full, null, urandom, stderr, stdout, stdin, and so on.

I believe this is an incorrect labeling, but I’m not sure why it is happening. The issue is that the SELinux policy that comes with centos 7 does not allow processes in docker containers to access file labeled with docker_tmpfs_t as those are supposed to be temporary files for the docker daemon itself not containers.


(Dev) #4

Looks like my issue may have been addressed in the 1.11.1 release by pull request [#22318 Fix mount label] (https://github.com/docker/docker/pull/22318)

I’ll check it out and report back.


(Dev) #5

1.11.1 did indeed fix the SELinux labeling for /dev