Come trovare un tipo SELinux appropriato per impedire il "permesso negato"

1

Obiettivo

Scopri una soluzione per evitare il permesso negato a causa di SELinux.

Sfondo

Distribuito un contenitore finestra mobile che monta il file host / var / run / docker ma non può accedervi all'interno del contenitore a causa di "Autorizzazione negata".

$ 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 

Il registro SELinux mostra sotto.

$ 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 processo che sta causando il permesso negato.

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

L'etichetta del processo negato.

$ 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

Concedere semplicemente il contesto del soggetto sul file di destinazione non funziona come non lo è per un oggetto file, suppongo. (Questo è confuso e come posso sapere quale tipo è per quali oggetti).

$ 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

Domanda

Aiuta a capire:

  1. Se la causa del permesso negato è solo dovuta a SELinux o meno.
  2. Come trovare il contesto / etichetta appropriata da dare e quale modificare (elaborare o archiviare).

Ricerca

Ci sono più articoli riguardanti la finestra mobile e SELinux che dice ai processi della finestra mobile di ereditare le etichette di svirt (VM) e dare a svirt_sandbox_file_t ma non ha funzionato.

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

1 risposta

1

Ho avuto un problema simile condividendo un socket X unix. Sebbene sia possibile condividere file regolari con flag z o Z , fallisce con i socket unix. Ne ho discusso qui:

link

La migliore soluzione generale che ho trovato è stata l'impostazione dell'opzione di esecuzione della finestra mobile:

--security-opt label=type:container_runtime_t

Tieni presente che questo probabilmente disabilita tutta la protezione SELinux per questo contenitore.

(Anche se, se vuoi condividere /var/run/docker.sock , hai già abbandonato tutti la protezione possibile dell'host, non solo SELinux. Sei sicuro di volerlo? )

    
risposta data 17.03.2018 - 16:24
fonte

Leggi altre domande sui tag