+++ This bug was initially created as a clone of Bug #1772025 +++ The openstack-selinux part of the bug is resolved, this is to handle the THT part of the fix. Description of problem: See below for the context set for /var/run/openvswitch, DPDK installation is failing with avc denied. type=AVC msg=audit(1573651690.514:4640): avc: denied { create } for pid=34421 comm="ovs-vswitchd" name="dpdk" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:container_file_t:s0 tclass=dir permissive=1 [root@overcloud-computeovsdpdksriov-1 ~]# ll -Z /var/run/openvswitch total 8 srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:37 br-tenant.mgmt srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:37 br-tenant.snoop srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 db.sock srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 ovsdb-server.17771.ctl -rw-r--r--. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 6 Nov 13 11:54 ovsdb-server.pid srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 ovs-vswitchd.17830.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 ovs-vswitchd.17881.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 ovs-vswitchd.17931.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 ovs-vswitchd.17981.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:54 ovs-vswitchd.18030.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:08 ovs-vswitchd.18322.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:08 ovs-vswitchd.18374.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:08 ovs-vswitchd.18424.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:08 ovs-vswitchd.18474.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:08 ovs-vswitchd.18523.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:14 ovs-vswitchd.19072.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:14 ovs-vswitchd.19124.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:14 ovs-vswitchd.19176.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:14 ovs-vswitchd.19227.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 13:14 ovs-vswitchd.19278.ctl srwxr-x---. 1 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 0 Nov 13 11:37 ovs-vswitchd.5063.ctl -rw-r--r--. 1 root root system_u:object_r:container_file_t:s0 41 Nov 13 11:54 useropts [root@overcloud-computeovsdpdksriov-1 ~]# ll -Z /var/run/openvswitch -d drwxr-xr-x. 2 openvswitch hugetlbfs system_u:object_r:container_file_t:s0 480 Nov 13 13:14 /var/run/openvswitch (undercloud) [stack@undercloud ~]$ cat /etc/yum.repos.d/latest-installed 16 -p RHOS_TRUNK-16.0-RHEL-8-20191112.n.1 [root@overcloud-computeovsdpdksriov-1 ~]# rpm -qa | grep openvswitch rhosp-openvswitch-2.11-0.3.el8ost.noarch network-scripts-openvswitch2.11-2.11.0-26.el8fdp.x86_64 openvswitch-selinux-extra-policy-1.0-19.el8fdp.noarch openvswitch2.11-2.11.0-26.el8fdp.x86_64 [root@overcloud-computeovsdpdksriov-1 ~]# rpm -qa | grep selinux selinux-policy-targeted-3.14.3-20.el8.noarch libselinux-ruby-2.9-2.1.el8.x86_64 python3-libselinux-2.9-2.1.el8.x86_64 libselinux-2.9-2.1.el8.x86_64 libselinux-utils-2.9-2.1.el8.x86_64 container-selinux-2.107-2.module+el8.1.0+4081+b29780af.noarch rpm-plugin-selinux-4.14.2-25.el8.x86_64 openstack-selinux-0.8.20-0.20191105125849.6578483.el8ost.noarch openvswitch-selinux-extra-policy-1.0-19.el8fdp.noarch selinux-policy-3.14.3-20.el8.noarch --- Additional comment from Aaron Conole on 2019-11-15 17:12:55 UTC --- SELinux context for /var/run/XXX should be set as the ovs daemons are started. Need someone from the selinux team to understand why this context is being set. Change the context back once this is understood. Neither OvS package nor ovs-selinux package set these explicitly. --- Additional comment from Julie Pichon on 2019-11-18 09:48:08 UTC --- Cédric, I know you helped with a number of patches to help openstack / openvswitch / containers to work well together, is this a case where we need some additional rules in openstack-selinux here? Or the context shouldn't have changed? Saravanan, would it be possible to attach the audit.log file? Were there any other related AVCs? --- Additional comment from Julie Pichon on 2019-11-18 09:51:34 UTC --- I am not seeing anything obvious in openstack-selinux that would change the context for /var/run/openvswitch so wondering if it may be related to something in THT. --- Additional comment from Saravanan KR on 2019-11-20 05:36:05 UTC --- --- Additional comment from Cédric Jeanneret on 2019-11-20 13:02:57 UTC --- Hello there Soooo... that location (/var/run/openvswitch) is mounted within containers: deployment/neutron/neutron-ovs-agent-container-puppet.yaml: - /var/run/openvswitch/:/var/run/openvswitch/:shared,z The "z" flag calls a relabelling, usually in order to prevent write (and read) access from within the container. In order to sort this situation, I think that a patch in openstack-selinux might be the right thing, allowing openvswitch_t to access/write into container_file_t. I don't think this opens any major security issue, and is probably better that way than allowing container_t to do stuff in openvswitch_file_t. Does it help, Julie? Sorry for the delay, didn't see that one before. Cheers, C. --- Additional comment from Cédric Jeanneret on 2019-11-25 07:25:07 UTC --- Note that we'll need to drop the ":z" flag from t-h-t as soon as we get a new package for openstack-selinux. That patch only (PR 46 against openstack-selinux) won't be sufficient. Not sure about the "shared" one, but iirc it is useless (no mount within the location). @Julie: feel free to ping me once a package is issued so that I can do the t-h-t modification+tests :). --- Additional comment from Julie Pichon on 2019-11-25 13:23:00 UTC --- Cédric, thanks! The patch is now included in package openstack-selinux-0.8.20-0.20191125121841.a4fcc2c.el8ost. I'm not sure whether to switch this bug to MODIFIED or if it needs to depend on or be reused for the THT fix you mention? --- Additional comment from Cédric Jeanneret on 2019-11-25 13:37:32 UTC --- @Julie: well, we probably want a new BZ for t-h-t, and add the depends-on + MODIFIED for the current one. -> is there already a BZ for t-h-t on that topic, or... ? Feel free to create it and give it to me. We'd "just" need to ensure upstream CI already has that package in order to not break things.
We will need an upstream backport to Train.
I think I'm wrong in there - we probably don't need to change t-h-t since the selinux change allows openvswitch_t to create dirs in container_file_t context. That said... I'm wondering if the new policy is enough since ovs will probably need to create files/sockets/others within those directories, and the context might be container_file_t as well. Need some testing on my side.
I think we may be fine for the files & sockets, see https://github.com/redhat-openstack/openstack-selinux/blob/master/os-podman.te / https://github.com/redhat-openstack/openstack-selinux/commit/c33f7560 manage_files_pattern(openvswitch_t, container_file_t, container_file_t) manage_sock_files_pattern(openvswitch_t, container_file_t, container_file_t) I remember being caught before where manage_files_pattern() allows r/w on files but not directory creation, which is the rule we were missing in bug 1772025. So we may be ok?
pretty sure we don't need to drop the ":z" flag - doing so would prevent the containers to actually write in that location, since container_t isn't allowed to write in openvswitch_var_run_file_t (or something like that). I've reverted upstream master patch (https://review.opendev.org/696074). Need some more testing on that.
I think this can probably be closed, or at least we're good in the context of bug 1772025 - the new rule was sufficient to resolve.
Closing as "NOTABUG" since, well, it's not a bug :).