what does the docker daemon option --selinux-enabled do

Question

I guess it will label the containers it started, but from the output of ps -eZ, I don't see any difference. For example, the container etcd has the same domain, no matter the daemon is with and without this option:

system_u:system_r:container_runtime_t:s0 16212 ? 00:00:00 dnsmasq-nanny

But it does prevent my container(k8s-dns-dnsmasq-nanny-amd64:1.14.8) from starting up and the deny logs shows access to /etc/localtime and /usr/sbin/dnsmasq are denied. I think these are files inside container filesystem. How can I write SELinux policy to allow access inside container file system?

Answer 1

Short Answer

• --selinux-enabled will enable an selinux policy which allows container processes labelled with svirt_lxc_net_t to read and write to files with the svirt_sandbox_file_t label.
• Container labels can be checked by inspecting the container using docker inspect -f '{{ .ProcessLabel }}' <container name> and docker inspect -f '{{ .MountLabel }}' <container name>

Long Answer

The --selinux-enabled option enables the docker selinux security policy, which is described in detail here. When enabled, this policy will:

• Label containers with the svirt_sandbox_file_t and svirt_lxc_net_t labels. This can be confirmed by running a container, and checking the labels applied to it:

  docker inspect <container id> | grep "Label"
  
  "MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c557,c611",
  "ProcessLabel": "system_u:system_r:svirt_lxc_net_t:s0:c557,c611",
  

  The svirt_sandbox_file_t is a MountLabel which restricts access to files on the host filesystem. The docker selinux docs say:

  If a file is labeled svirt_sandbox_file_t, then by default all containers can read it. But if the containers write into a directory that has svirt_sandbox_file_t ownership, they write using their own category

  The category in the example above is c557,c611.

  The svirt_lxc_net_t is used to protect processes. According to the redhat solution here, it is used to:

  ... isolate the container processes from the host, and it generates a unique Multi-Category Security label to allow SELinux to prevent one container process from attacking other container processes and content.

Your access issue is most likely occurring because the selinux labels on the host filesystem are preventing access from within the container. For example, the selinux docs say:

By default, docker gets access to everything in /usr and most things in /etc.

So your options are to either:

1. Manually relabel the files on the hosts system with system_u:object_r:svirt_sandbox_file_t. This is often not recommended for system files and directories as it can have unintended effects on the host.

2. Run the container as an unconfined type. This will disable isolation for this container only while still continuing to enforce selinux on the host:

   docker run -it --security-opt label:disable alpine sh