SELinux is not namespaced
This means that there is only one SELinux rules base for all containers on a system. When we attempt to confine containers we want to prevent them from writing to kernel file systems, which might be one mechanism for escape. One of those file systems would be /proc/fs/selinux, and we also want to control there access to things like /proc/self/attr/* field.
By default Docker processes run as svirt_lxc_net_t and they are prevented from doing (almost) all SELinux operations. But processes within containers do not know that they are running within a container. SELinux aware applications are going to attempt to do SELinux operations, especially if they are running as root.
For example, if you are running yum/dnf/rpm inside of a docker build container and the tools sees that SELinux is enabled, the tool is going to attempt to set labels on the file system, if SELinux blocks the setting of these file labels these calls will fail causing the tool will fail and exit. Because of it SELinux aware applications within containers would mostly fail.
Libselinux is a liar
We obviously do not want these apps failing, so we decided to make libselinux lie to the processes. libselinux checks if /proc/fs/selinux is mounted onto the system and whether it is mounted read/write. If /proc/fs/selinux not mounted read/write, libselinux will report to calling applications that SELinux is disabled. In containers we don't mount these file systems by default or we mount it read/only causing libselinux to report that it is disabled.
# getenforce
Enforcing
# docker run --rm fedora id -Z
id: --context (-Z) works only on an SELinux-enabled kernel
# docker run --rm -v /sys/fs/selinux:/sys/fs/selinux:ro fedora id -Z
id: --context (-Z) works only on an SELinux-enabled kernel
# docker run --rm -v /sys/fs/selinux:/sys/fs/selinux fedora id -Z
system_u:system_r:svirt_lxc_net_t:s0:c19
When SELinux aware applications like yum/dnf/rpm see SELinux is disabled, they stop trying to do SELinux operations, and succeed within containers.
Applications work well even though SELinux is very much enforcing, and controlling their activity.
I believe that SELInux is the best tool we currently use to make Contaieners actually contain.
In this case SELinux disabled does not make me cry.
Somewhat releated... Sometimes SElinux denies access but doesn't log
The only way we knew for sure that the problem was SELinux was that we set setenfoce=0 the problem went away. (In once instance an application was trying to create a directory, in another Apache was trying to follow a symlink) Anyone have any idea why this happens and how we can find the root of the problem without disabling SELinux?
Re: Somewhat releated... Sometimes SElinux denies access but doesn't log
http://danwalsh.livejournal.com/11673.html
Re: Somewhat releated... Sometimes SElinux denies access but doesn't log
Thanks!
VM's inside a container
Is there a way to isolate those VM's from each other using selinux?
Re: VM's inside a container
RE: Re: VM's inside a container
[user@localhost ~]$ ps -efZ | grep docker
system_u:system_r:docker_t:s0 root 7327 1 1 10:23 ? 00:00:28 /usr/bin/dockerd -H unix:///var/run/docker.sock --selinux-enabled
[user@localhost ~]$ docker run --rm -v /sys/fs/selinux:/sys/fs/selinux fedora id -Z
Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
ffa7676a36a8: Pull complete
Digest: sha256:be1e975ca0832971c21e6876eeea4d2a1
Status: Downloaded newer image for fedora:latest
id: --context (-Z) works only on an SELinux-enabled kernel
Re: Re: VM's inside a container
Try touch /etc/selinux/config.
# docker run -ti -v /sys/fs/selinux/:/sys/fs/selinux strace sh
# id -Z
id: --context (-Z) works only on an SELinux-enabled kernel
# touch /etc/selinux/config
# id -Z
system_u:system_r:container_t:s0:c700,c9
# exit