2

Objective

Find out a solution to avoid the permission denied due to SELinux.

Background

Deployed a docker container which mounts the host file /var/run/docker but cannot access it within the container due to "Permission denied".

$ ls -Z /var/run/docker.sock
srw-rw----. root root system_u:object_r:container_var_run_t:s0 /var/run/docker.sock

$  sudo semanage fcontext -l | grep '/var/run/docker'
/var/run/docker\.sock                              socket             system_u:object_r:container_var_run_t:s0 

The SELinux log shows below.

$ sudo cat /var/log/audit/audit.log | grep sock
type=AVC msg=audit(1516519533.557:1465348): avc:  denied  { connectto } for  pid=54437 comm="python" path="/run/docker.sock" scontext=system_u:system_r:svirt_lxc_net_t:s0:c556,c641 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1516519533.966:1465349): avc:  denied  { connectto } for  pid=54440 comm="python" path="/run/docker.sock" scontext=system_u:system_r:svirt_lxc_net_t:s0:c556,c641 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket

Process IDs which is causing the permission denied.

root      53831  0.0  0.0 216508  1932 ?        Sl   18:24   0:00      \_ /usr/bin/docker-containerd-shim-current 28b7eb84ebfccd297ea18352b38b765f1f3ede5e03fb9f29b3218b7355110b7e /var/run/docker/libcontainerd/28b7eb84ebfccd297ea18352b38b765f1f3ede5e03fb9f29b3218b7355110
1001      53846  0.0  0.0   2668   720 ?        Ssl  18:24   0:00      |   \_ /pod
root      54329  0.0  0.0 280636  1932 ?        Sl   18:24   0:00      \_ /usr/bin/docker-containerd-shim-current 149bb5c7d37b4335ade587d7a1b38331b48ffe7ae83c865fd4afc2dbc2fccc4f /var/run/docker/libcontainerd/149bb5c7d37b4335ade587d7a1b38331b48ffe7ae83c865fd4afc2dbc2fcc
root      54345  0.1  0.1  95800 19040 ?        Ss   18:24   0:03          \_ /opt/datadog-agent/embedded/bin/python /opt/datadog-agent/bin/supervisord -n -c /etc/dd-agent/supervisor.conf
root      54435  0.0  0.0 275920  5732 ?        Sl   18:24   0:01              \_ /opt/datadog-agent/bin/trace-agent
root      54436  0.2  0.2 173424 40456 ?        S    18:24   0:07              \_ /opt/datadog-agent/embedded/bin/python /opt/datadog-agent/agent/ddagent.py
root      54437  0.1  0.2 219256 37668 ?        Sl   18:24   0:05              \_ /opt/datadog-agent/embedded/bin/python /opt/datadog-agent/agent/dogstatsd.py --use-local-forwarder
root      54440  1.4  0.3 320204 57180 ?        S    18:24   0:50              \_ /opt/datadog-agent/embedded/bin/python /opt/datadog-agent/agent/agent.py foreground --use-local-forwarder

The label of the denied process.

$ ps -Z -P 54440
LABEL                              PID PSR TTY      STAT   TIME COMMAND
system_u:system_r:svirt_lxc_net_t:s0:c556,c641 54440 1 ? S   1:56 /opt/datadog-agent/embedded/bin/python /opt/datadog-agent/agent/agent.py foreground --use-local-forwarder

Simply granting the subject context on the target file does not work as it is not for a file object, I suppose. (This is confusing and how I can know which type is for which objects).

$ sudo semanage fcontext -a -t svirt_lxc_net_t "/var/run/docker.sock"
ValueError: Type svirt_lxc_net_t is invalid, must be a file or device type

Question

Please help understand:

  1. If the cause of permission denied is only due to the SELinux or not.
  2. How to find the appropriate context/label to give, and which one to change (process or file).

Research

There are multiple articles regarding docker and SELinux which tells docker processes inherit svirt (VM) labels and give svirt_sandbox_file_t but it did not work.

chcon -R -t svirt_sandbox_file_t /var/run/docker.sock
2

I had a similar issue sharing an X unix socket. While sharing regular files with flags z or Z is possible, it fails with unix sockets. I have discussed it here:

https://unix.stackexchange.com/questions/386767/selinux-and-docker-allow-access-to-x-unix-socket-in-tmp-x11-unix

The best general solution I found was to set docker run option:

--security-opt label=type:container_runtime_t

Be aware that this probably disables all SELinux protection for this container.

(Though, if you want to share /var/run/docker.sock you already give up all possible protection of the host, not only SELinux. Are you sure you want that?)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.