ちょっと自前の色々動かしているマシンAで検証してたgitlabを専用のマシンBで動かそうとしたときにSELinux絡みで色々ハマった話。
プロセス監視ツールでそういうことあるもんなんですね。
環境について
マシンAについて
- CentOS 7.2.1511
- supervisorでプロセス監視
- rundeckやらgitbucketやらjenkinsやら色々動かしてる
- SELinuxはEnforcingで稼働、特に設定はいじってない
マシンBについて
- CentOS 7.4.1708
- systemdでプロセス監視
- 1からセットアップ、nginxとdocker, docker-compose以外には入れてない
ハマった事象について
マシンBでセットアップした際、nginxからdocker内のgitlabへupstreamを行う際にSELinuxがカンカンになった。
type=AVC msg=audit(1514365997.822:555): avc: denied { name_connect } for pid=1903 comm="nginx" dest=8088 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1514365997.822:555): arch=c000003e syscall=42 success=no exit=-13 a0=d a1=55af561b1f20 a2=10 a3=7ffe38ce41d0 items=0 ppid=1902 pid=1903 auid=4294967295 uid=998 gid=994 euid=998 suid=998 fsuid=998 egid=994 sgid=994 fsgid=994 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null)
検証機を用意してsetools-consoleをインストールして状況を確認すると以下の塩梅だった。httpd_can_network_connectが原因で蹴られている。
[test@localhost ~]$ sesearch -A -C -s httpd_t -t unreserved_port_t -c tcp_socket
Found 5 semantic av rules:
allow httpd_t port_type : tcp_socket { recv_msg send_msg } ;
DT allow httpd_t port_type : tcp_socket name_connect ; [ httpd_can_network_connect ]
DT allow nsswitch_domain unreserved_port_t : tcp_socket name_connect ; [ nis_enabled ]
DT allow nsswitch_domain unreserved_port_t : tcp_socket name_bind ; [ nis_enabled ]
DT allow nsswitch_domain port_type : tcp_socket { recv_msg send_msg } ; [ nis_enabled ]
これ自体はsetsebool httpd_can_network_connect on -Pで対応出来た。
だが色々やってるマシンAではこんな設定入れてない。何故動く？
解決
マシンAとBでプロセスのセキュリティコンテキストを見比べたら分かった。supervisorで動かした場合とsystemdで動かした場合でプロセスのタイプの部分が異なる。
マシンA抜粋
[test@localhost ~]$ ps auxeZ | grep nginx
system_u:system_r:unconfined_service_t:s0 root 3990 0.0 0.0 46100 3668 ? S 18:03 0:00 nginx: master process /usr/sbin/nginx
system_u:system_r:unconfined_service_t:s0 nginx 3992 0.0 0.0 46676 3492 ? S 18:03 0:00 nginx: worker process
マシンB抜粋
[test@localhost ~]$ ps auxeZ | grep nginx
system_u:system_r:httpd_t:s0 root 1902 0.0 0.0 46308 1004 ? Ss 12:05 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
system_u:system_r:httpd_t:s0 nginx 1903 0.0 0.0 46892 3488 ? S 12:05 0:00 nginx: worker process
unconfined、ということでsesearchの結果を見ても一切制約がかかってないのが分かる。
それゆえに成功していたということだが、むしろこっちの方が悪くないか……？実質SELinuxをdisabledで稼働させてるのと大差ない
setseboolで個別に許可出すのが最適解なんだろうか。
[test@localhost ~]$ sesearch -A -C -s unconfined_service_t -t unreserved_port_t -c tcp_socket
Found 1 semantic av rules:
allow corenet_unconfined_type port_type : tcp_socket { recv_msg send_msg name_bind name_connect } ;
supervisorの下で動かす際のSELinuxのプロセスタイプをどうすりゃ設定出来るのかは結局分からなかった。
ネットのブログだの見るとsetenforce 0する、なんて記述があり溢れてるしみんなそういうところは気にしないもんなんだろうか？