Cómo encontrar un tipo de SELinux apropiado para evitar el "permiso denegado"

1

Objetivo

Encuentre una solución para evitar el permiso denegado debido a SELinux.

Fondo

Implementó un contenedor de ventana acoplable que monta el archivo host / var / run / docker pero no puede acceder a él dentro del contenedor debido a "Permiso denegado".

$ 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 

El registro de SELinux se muestra a continuación.

$ 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

ID de proceso que están causando el permiso denegado.

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

La etiqueta del proceso denegado.

$ 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

El simple hecho de conceder el contexto del sujeto en el archivo de destino no funciona, ya que no es para un objeto de archivo, supongo. (Esto es confuso y cómo puedo saber qué tipo es para qué objetos).

$ 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

Pregunta

Por favor, ayuda a entender:

  1. Si la causa del permiso denegado se debe solo a SELinux o no.
  2. Cómo encontrar el contexto / etiqueta apropiado para dar, y cuál cambiar (proceso o archivo).

Investigación

Hay varios artículos relacionados con la ventana acoplable y SELinux que le dice a los procesos de la ventana acopladora que heredan las etiquetas svirt (VM) y le dan svirt_sandbox_file_t pero no funcionó.

chcon -R -t svirt_sandbox_file_t /var/run/docker.sock
    
pregunta mon 21.01.2018 - 09:42
fuente

1 respuesta

1

Tuve un problema similar al compartir un socket X unix. Aunque es posible compartir archivos normales con marcas z o Z , falla con sockets de unix. Lo he discutido aquí:

enlace

La mejor solución general que encontré fue establecer la opción de ejecución de la ventana acoplable:

--security-opt label=type:container_runtime_t

Tenga en cuenta que esto probablemente deshabilite toda la protección de SELinux para este contenedor.

(Aunque, si desea compartir /var/run/docker.sock , ya está renunciando a all posible protección del host, no solo SELinux. ¿Está seguro de que desea eso? )

    
respondido por el mviereck 17.03.2018 - 16:24
fuente

Lea otras preguntas en las etiquetas