I installed Gitlab on my Rocky Linux machine. It works as long as I put SELinux into permissive mode with setenforce 0. I’d like to turn on SELinux back on, but then when I access Gitlab that causes a violation when my NGINX instance wants to connect to gitlab-workhorse socket (it’s local NGINX running on the same machine but not the one bundled with gitlab).
Here is the message from audit.log: type=AVC msg=audit(1723445215.637:9909): avc: denied { connectto } for pid=1338 comm="nginx" path="/var/opt/gitlab/gitlab-workhorse/sockets/socket" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
ls -lZ /var/opt/gitlab/gitlab-workhorse/sockets/socket srwxrwxrwx. 1 gitlab-base gitlab-base system_u:object_r:gitlab_shell_t:s0 0 Aug 11 14:24 /var/opt/gitlab/gitlab-workhorse/sockets/socket
I also tried doing
sudo -u nginx nc -U /var/opt/gitlab/gitlab-workhorse/sockets/socket
and that connects successfully.
I don’t really understand why does the connection from NGINX happen under unconfined_service_t context. That is probably the issue but I have no idea how to sort this out.
If you have some thoughts or see the problem right away, please help, I have no clue.
–EDIT–
Ah yes, I forgot, here are the relevant rules on my system:
allow httpd_t gitlab_shell_t:sock_file { read write };
allow httpd_t gitlab_shell_t:unix_stream_socket connectto;
scontext is the action’s source (httpd_t), tcontext is the action’s target (unconfined_service_t). gitlab is what is running as unconfined_service_t, not nginx.
I would look further into audit2why -i /var/log/audit/audit.log and audit2allow -i /var/log/audit/audit.log and see what new suggestions it gives you.
When we ran git.rockylinux.org with an external nginx, we used to run chcon -t httpd_var_run_t against the sockets. This may work for you, but they stop working during updates/upgrades.
Yes, it does run as unconfined_service_t, but how come it is the workhorse’s process type being used as tcontext as opposed to the type on the socket (which is gitlab_shell_t)?
Anyway, this is a good point, I may as well try out what happens if I manage to run workhorse as gitlab_shell_t. Thank you!
– EDIT –
OK, I did a quick readup, now I understand why it’s unconfined_service_t. All clear, thank you very much!
I use the nginx bundled with Gitlab, and it works fine for me with enforcing selinux. I expect the problem here is because you are using the external nginx instead. It seems the selinux contexts are perfectly fine otherwise when using the bundled nginx with Gitlab. Obviously at this point, for any external processes for example running your own nginx like you are, means you have to resolve the selinux contexts yourself since the Gitlab package cannot do that for you. At least, unless you use the bundled nginx that is.
Yes, but look at those rules though. There is rule that allows httpd_t to connect to that port, doesn’t matter where NGINX comes from. It should still work.