ちょっと自前の色々動かしているマシン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する、なんて記述があり溢れてるしみんなそういうところは気にしないもんなんだろうか？