Bug 1997182
| Summary: | Need to allow haproxy_t self:unix_stream_socket connectto | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Ryan O'Hara <rohara> | |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | |
| Status: | CLOSED ERRATA | QA Contact: | Amith <apeetham> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 9.0 | CC: | bperkins, lvrabec, mmalik, ssekidde | |
| Target Milestone: | rc | Keywords: | AutoVerified, Triaged | |
| Target Release: | 9.0 | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-34.1.16-1.el9 | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2015423 (view as bug list) | Environment: | ||
| Last Closed: | 2022-05-17 15:49:27 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2015423 | |||
Note that enabling the 'daemons_enable_cluster_mode' boolean will resolve this problem, but I am no sure that is the preferred solution since customers will likely expect this feature to work by default. Interested to hear what selinux team has to say on this. # rpm -qa selinux\* haproxy\* | sort
haproxy-2.4.3-1.el9.x86_64
selinux-policy-34.1.13-1.el9.noarch
selinux-policy-devel-34.1.13-1.el9.noarch
selinux-policy-targeted-34.1.13-1.el9.noarch
#
The following SELinux denial appeared in enforcing mode:
----
type=PROCTITLE msg=audit(08/26/2021 14:33:22.862:375) : proctitle=/usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
type=PATH msg=audit(08/26/2021 14:33:22.862:375) : item=0 name=/var/run/haproxy.sock inode=1216 dev=00:19 mode=socket,600 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:haproxy_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(08/26/2021 14:33:22.862:375) : cwd=/
type=SOCKADDR msg=audit(08/26/2021 14:33:22.862:375) : saddr={ saddr_fam=local path=/var/run/haproxy.sock }
type=SYSCALL msg=audit(08/26/2021 14:33:22.862:375) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x7 a1=0x7ffdf7dd6120 a2=0x6e a3=0x66 items=1 ppid=1 pid=16778 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=haproxy exe=/usr/sbin/haproxy subj=system_u:system_r:haproxy_t:s0 key=(null)
type=AVC msg=audit(08/26/2021 14:33:22.862:375) : avc: denied { connectto } for pid=16778 comm=haproxy path=/run/haproxy.sock scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=unix_stream_socket permissive=0
----
The same SELinux denial appeared in permissive mode:
----
type=PROCTITLE msg=audit(08/26/2021 14:35:03.289:386) : proctitle=/usr/sbin/haproxy -sf 21584 -x /var/run/haproxy.sock -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
type=PATH msg=audit(08/26/2021 14:35:03.289:386) : item=0 name=/var/run/haproxy.sock inode=1234 dev=00:19 mode=socket,600 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:haproxy_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(08/26/2021 14:35:03.289:386) : cwd=/
type=SOCKADDR msg=audit(08/26/2021 14:35:03.289:386) : saddr={ saddr_fam=local path=/var/run/haproxy.sock }
type=SYSCALL msg=audit(08/26/2021 14:35:03.289:386) : arch=x86_64 syscall=connect success=yes exit=0 a0=0x7 a1=0x7ffde0c13fe0 a2=0x6e a3=0x66 items=1 ppid=1 pid=21582 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=haproxy exe=/usr/sbin/haproxy subj=system_u:system_r:haproxy_t:s0 key=(null)
type=AVC msg=audit(08/26/2021 14:35:03.289:386) : avc: denied { connectto } for pid=21582 comm=haproxy path=/run/haproxy.sock scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=unix_stream_socket permissive=1
----
@QA: The reload operation is necessary. These AVCs do not appear without reloading of the haproxy service.
(In reply to Ryan O'Hara from comment #1) > Note that enabling the 'daemons_enable_cluster_mode' boolean will resolve > this problem, but I am no sure that is the preferred solution since > customers will likely expect this feature to work by default. Interested to > hear what selinux team has to say on this. Setroubleshoot is able to find a way how to allow the permission, it is unable to assess though if the access is not overpermissive. It is. # sesearch -A -b daemons_enable_cluster_modee allow daemon cluster_conf_t:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink write }; [ daemons_enable_cluster_mode ]:True ...a few dozen lines follow I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/881 Commit to backport:
commit b430a991f8eb0d0a4d593ec88e07144d5cb79cdf (HEAD -> rawhide, upstream/rawhide)
Author: Zdenek Pytela <zpytela>
Date: Tue Sep 21 19:35:22 2021 +0200
Support hitless reloads feature in haproxy
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: selinux-policy), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:3918 |
HAProxy has long had a feature for "hitless reloads" [1] that prevents established connections from being dropped due to a reload. The way to achieve this is the setup a stats socket with keyword 'expose-fd listeners': stats socket /var/run/haproxy.sock mode 600 expose-fd listeners level user However, this will trigger an AVC when reload occurs due to haproxy itself not being able to connect to the stats socket: # systemctl start haproxy # systemctl reload haproxy Now, checking audit.log: # grep denied /var/log/audit/audit.log type=AVC msg=audit(1629815894.374:1139): avc: denied { read } for pid=11431 comm="haproxy" name="node" dev="sysfs" ino=614 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1629815894.378:1140): avc: denied { connectto } for pid=11431 comm="haproxy" path="/run/haproxy.sock" scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=unix_stream_socket permissive=0 # grep denied /var/log/audit/audit.log | audit2allow #============= haproxy_t ============== #!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode' allow haproxy_t self:unix_stream_socket connectto; allow haproxy_t sysfs_t:dir read; The sysfs_t:dir read AVC is due to a separate issues (see rhbz#1995256). [1] https://www.haproxy.com/blog/hitless-reloads-with-haproxy-howto/