web-dev-qa-db-ja.com

「アクセスが拒否されました」を防ぐために適切なSELinuxタイプを見つける方法

目的

SELinuxによって拒否された権限を回避するための解決策を見つけてください。

バックグラウンド

Hostファイル/ var/run/dockerをマウントするDockerコンテナをデプロイしましたが、「アクセスが拒否されました」のためにコンテナ内でアクセスできません。

$ 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

SELinuxログを以下に示します。

$ 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が拒否されました。

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

拒否されたプロセスのラベル。

$ 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

おそらく、ターゲットファイルのサブジェクトコンテキストを付与するだけでは機能しません。ファイルオブジェクトの場合はそうではないからです。 （これは紛らわしく、どのオブジェクトがどのタイプかをどのようにして知ることができるか）。

$ 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

質問

理解してください：

  1. 許可が拒否された原因がSELinuxのみに起因するかどうか。
  2. 与える適切なコンテキスト/ラベルを見つける方法、および変更するもの（プロセスまたはファイル）。

研究

DockerとSELinuxに関する複数の記事があり、Dockerプロセスがsvirt（VM）ラベルを継承してsvirt_sandbox_file_tを提供することを伝えていますが、機能しませんでした。

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

X UNIXソケットを共有する同様の問題がありました。フラグzまたはZを使用して通常のファイルを共有することは可能ですが、UNIXソケットでは失敗します。私はそれをここで議論しました：

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

私が見つけた最も一般的な解決策は、docker runオプションを設定することでした：

--security-opt label=type:container_runtime_t

これにより、このコンテナのすべてのSELinux保護が無効になる可能性があることに注意してください。

（ただし、共有したい場合は/var/run/docker.sock SELinuxだけでなく、ホストのall可能な保護をすでにあきらめています。よろしいですか？）

2
mviereck