Description of problem: icmp health monitors are broken in rhosp16.1 to what appears to be a selinux restriction: type=AVC msg=audit(1655139457.142:1084): avc: denied { execute } for pid=7087 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139460.518:1090): avc: denied { execute } for pid=7093 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139461.328:1091): avc: denied { execute } for pid=7094 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139462.247:1113): avc: denied { execute } for pid=7132 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139465.621:1118): avc: denied { execute } for pid=7157 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139466.431:1119): avc: denied { execute } for pid=7158 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139467.349:1120): avc: denied { execute } for pid=7159 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139470.722:1121): avc: denied { execute } for pid=7164 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139471.532:1122): avc: denied { execute } for pid=7165 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 type=AVC msg=audit(1655139472.450:1125): avc: denied { execute } for pid=7167 comm="haproxy" name="bash" dev="vda1" ino=4215375 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1655139472.452:1126): avc: denied { execute } for pid=7168 comm="ping-wrapper.sh" name="ping" dev="vda1" ino=4215754 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:ping_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1655139472.452:1126): avc: denied { read open } for pid=7168 comm="ping-wrapper.sh" path="/usr/bin/ping" dev="vda1" ino=4215754 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:ping_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1655139472.452:1126): avc: denied { execute_no_trans } for pid=7168 comm="ping-wrapper.sh" path="/usr/bin/ping" dev="vda1" ino=4215754 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:object_r:ping_exec_t:s0 tclass=file permissive=1 type=AVC msg=audit(1655139472.457:1127): avc: denied { setcap } for pid=7168 comm="ping" scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=process permissive=1 type=AVC msg=audit(1655139472.457:1128): avc: denied { create } for pid=7168 comm="ping" scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=icmp_socket permissive=1 type=AVC msg=audit(1655139472.457:1129): avc: denied { create } for pid=7168 comm="ping" scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=rawip_socket permissive=1 type=AVC msg=audit(1655139472.457:1130): avc: denied { setopt } for pid=7168 comm="ping" lport=1 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=rawip_socket permissive=1 type=AVC msg=audit(1655139472.457:1131): avc: denied { getopt } for pid=7168 comm="ping" lport=1 scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=rawip_socket permissive=1 type=AVC msg=audit(1655139496.100:1133): avc: denied { execmem } for pid=7217 comm="haproxy" scontext=system_u:system_r:haproxy_t:s0 tcontext=system_u:system_r:haproxy_t:s0 tclass=process permissive=1 [root@amphora-511460b7-c49e-4e3c-aa25-b40b6a162d4a audit]# grep denied audit.log | audit2allow -R require { type haproxy_t; type shell_exec_t; type ping_exec_t; class process { execmem setcap }; class icmp_socket create; class rawip_socket { create getopt setopt }; class file { execute execute_no_trans open read }; } #============= haproxy_t ============== allow haproxy_t ping_exec_t:file { execute execute_no_trans open read }; allow haproxy_t self:icmp_socket create; #!!!! This avc can be allowed using the boolean 'cluster_use_execmem' allow haproxy_t self:process execmem; allow haproxy_t self:process setcap; allow haproxy_t self:rawip_socket { create getopt setopt } Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hello there, IMHO, the fix should be: - add 2 new rules to the openstack-selinux[1], activated via a new boolean "haproxy_ping": require { type haproxy_t; type ping_exec_t; class icmp_socket create; class file { execute execute_no_trans open read }; } #============= haproxy_t ============== allow haproxy_t ping_exec_t:file { execute execute_no_trans open read }; allow haproxy_t self:icmp_socket create; - add an option the operator can toggle at the LB creation that will then toggle both haproxy_ping and cluster_use_execmem That way, we: - allow this specific usage - but also ensure we're not enabling it by default everywhere @jpichon any thoughts? We should also check what is actually available via the cluster_use_execmem - maybe it's something we should cover in the "haproxy_ping" if it opens too many things. @gthiemon does it sounds doable? Especially the "pass a parameter at LB creation". @dhill would this solution be OK? It would require recreating the LB in order to toggle the option, but since CU will have to redeploy the new image in order to get the new openstack-selinux, it shouldn't be that bad.. ? Cheers, C. [1] https://github.com/redhat-openstack/openstack-selinux/blob/master/os-octavia.te
I don't think there is a need to change the Octavia API here. You could toggle your selinux rules when the health monitor of type PING is created.
(In reply to Cédric Jeanneret from comment #9) > @jpichon any thoughts? We should also check what is actually > available via the cluster_use_execmem - maybe it's something we should cover > in the "haproxy_ping" if it opens too many things. These rules behind a new boolean look fine to me. cluster_use_execmem is limited to allowing execmem for the cluster_domain process [1] and looks fine as well. "allow haproxy_t self:process setcap;" shows outside of the cluster_use_execmem boolean in my audit2allow output though, so we may have to add it under the custom boolean too? I'm not sure what's the selinux-policy version on the system from the description, it would be good to compare. [1] https://github.com/fedora-selinux/selinux-policy/blob/9cb8de3f5d06e2624d728b97ab23d08321b0ad9a/policy/modules/contrib/rhcs.te#L132
> @gthiemon does it sounds doable? Especially the "pass a parameter > at LB creation". we could enable the SELinux policy exceptions at runtime when a HM of type PING is created, but I'm afraid that this code would not be fully tested upstream (default gates are based on ubuntu, we have also some centos jobs but selinux is configured as permissive). we also have an existing patch to enable a SELinux boolean when building the amphora image (https://review.opendev.org/c/openstack/octavia/+/840315) I would rather keep those booleans in a single location.
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 (Red Hat OpenStack Platform 16.1.9 bug fix and enhancement advisory), 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:8795