Constant SELinux alerts trying to access name_connect on tcp_socket port 443 since 11.1 update
Summary
Since the automatic update to 11.1 there are constant SELinux errors (like one per second) regarding access to name_connect on a TCP socket. This does not happen with version 11.0.
Downgrading to 11.0 fixes the problem.
Steps to reproduce
Setup a Fedora 28 with SELinux and update gitlab-runner to 11.1.
Actual behavior
Every second SELinux warns about the access violation of gitlab-runner.
Expected behavior
No SELinux errors should happen.
Relevant logs and/or screenshots
SELinux is preventing gitlab-runner from name_connect access on the tcp_socket port 443.
***** Plugin catchall_boolean (89.3 confidence) suggests ******************
If you want to allow nis to enabled
Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.
Do
setsebool -P nis_enabled 1
***** Plugin catchall (11.6 confidence) suggests **************************
If you believe that gitlab-runner should be allowed name_connect access on the port 443 tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'gitlab-runner' --raw | audit2allow -M my-gitlabrunner
# semodule -X 300 -i my-gitlabrunner.pp
Additional Information:
Source Context system_u:system_r:init_t:s0
Target Context system_u:object_r:http_port_t:s0
Target Objects port 443 [ tcp_socket ]
Source gitlab-runner
Source Path gitlab-runner
Port 443
Host bushart
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.14.1-32.fc28.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name bushart
Platform Linux bushart 4.17.7-200.fc28.x86_64 #1 SMP Tue
Jul 17 16:28:31 UTC 2018 x86_64 x86_64
Alert Count 175
First Seen 2018-07-23 10:24:39 CEST
Last Seen 2018-07-23 10:29:15 CEST
Local ID f801e105-918c-45eb-9671-3063c02d3289
Raw Audit Messages
type=AVC msg=audit(1532334555.214:69573): avc: denied { name_connect } for pid=12899 comm="gitlab-runner" dest=443 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
Hash: gitlab-runner,init_t,http_port_t,tcp_socket,name_connectEnvironment description
Fedora 28 and gitlab-runner with docker executor
Used GitLab Runner version
Version: 11.1.0
Git revision: 081978aa
Git branch:
GO version: go1.8.7
Built: 2018-07-22T07:24:46+00:00
OS/Arch: linux/amd64Proposal
Current state
The issue seems to be related to the usage of gitlab-runner as a service. Currently the RPM package installs the following layout:
/usr/bin/gitlab-runner -> ../lib/gitlab-runner/gitlab-runner
/usr/lib/gitlab-runner/gitlab-runner
/usr/lib/gitlab-runner/helper-images/prebuilt-*.tar.xzWhen the /usr/bin/gitlab-runner executable is run with the install command, it will generate a /etc/systemd/system/gitlab-runner.service file based on the path of the running executable, which instead of being /usr/bin/gitlab-runner is the target of the symlink, /usr/lib/gitlab-runner/gitlab-runner. The problem with this is that it will run in the lib_t SELinux context type, rather than the intended bin_t one.
The Runner will look for Docker helper images in ./helper-images/ sub-directory.
Proposed change
- Get rid of the symlink and put the actual binary in
/usr/binso that the service definition is generated with the correct path. - Move the Docker helper images to
/usr/libexec/gitlab-runner/helper-images, which seems to make more sense according to the specs
Proposed new layout:
/usr/bin/gitlab-runner
/usr/libexec/gitlab-runner/helper-images/prebuilt-*.tar.xzThe Runner would then try to find Docker images in ../libexec/gitlab-runner/helper-images/ (only for Linux binaries), in addition to ./helper-images/.