Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
This request needs to be satisfied by updating the selinux targetted package, iirc. I have one update ready to go, but we will need to run a few different devices and scenarios to make sure that we capture all of the cases. UIO, VFIO, and vhost-user are the ones I'm thinking. I will obtain captures and try to write up a patch for the targetted policy in the next week.
I believe the following selinux policy should cover vfio and vhost-user, but you'll need to test. Also note that for vhost-user changes, you'll definitely need a change to the libvirt policy. I haven't tested with uio. Not sure how to get this into the selinux-policy or whether we should ship it as part of the ovs package (flavio / anita?)
module openvswitch-policy 1.0.1;
require {
type openvswitch_t;
type openvswitch_tmp_t;
type openvswitch_var_run_t;
type ifconfig_exec_t;
type hostname_exec_t;
type vfio_device_t;
type kernel_t;
type tun_tap_device_t;
type hugetlbfs_t;
type init_t;
class netlink_socket { setopt getopt create connect getattr write read };
class file { write getattr read open execute execute_no_trans create unlink };
class chr_file { write getattr read open ioctl };
class unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };
class dir { write remove_name add_name lock read };
}
#============= openvswitch_t ==============
allow openvswitch_t self:netlink_socket { setopt getopt create connect getattr write read };
allow openvswitch_t hostname_exec_t:file { read getattr open execute execute_no_trans };
allow openvswitch_t ifconfig_exec_t:file { read getattr open execute execute_no_trans };
allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };
allow openvswitch_t openvswitch_tmp_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };
allow openvswitch_t vfio_device_t:chr_file { read write open ioctl getattr };
allow openvswitch_t tun_tap_device_t:chr_file { read write getattr open ioctl };
allow openvswitch_t hugetlbfs_t:dir { write remove_name add_name lock read };
allow openvswitch_t hugetlbfs_t:file { create unlink };
allow openvswitch_t kernel_t:unix_stream_socket { write getattr read connectto connect setopt getopt sendto accept bind recvfrom acceptfrom };
allow openvswitch_t init_t:file { read open };
Description of problem: RFE: OVS-dpdk daemon won't start due to AVC denial with SELINUX=enforcing Currently, In a dpdk environment OVS daemon won't start with SELINUX=enforcing as it gets AVC denial: type=AVC msg=audit(1475082194.788:1788): avc: denied { read write } for pid=64221 comm="ovs-vswitchd" name="vfio" dev="devtmpfs" ino=396 scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:object_r:vfio_device_t:s0 tclass=chr_file type=SYSCALL msg=audit(1475082194.788:1788): arch=c000003e syscall=2 success=no exit=-13 a0=7fbdfb2ddcd0 a1=2 a2=7fbdf9a6f7b8 a3=7fbdf97e89d0 items=0 ppid=64104 pid=64221 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ovs-vswitchd" exe="/usr/sbin/ovs-vswitchd" subj=system_u:system_r:openvswitch_t:s0 key=(null) type=SERVICE_START msg=audit(1475082204.498:1789): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=openvswitch-nonetwork comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=SERVICE_START msg=audit(1475082204.502:1790): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=openvswitch comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' This BZ is to request an enhancement so that the daemon will start with SELINUX=enforcing. Version-Release number of selected component (if applicable): [root@netqe5 audit]# rpm -qa | grep openvswitch openvswitch-2.5.0-5.git20160628.el7fdb.x86_64 [root@netqe5 audit]# uname -a Linux netqe5.knqe.lab.eng.bos.redhat.com 3.10.0-510.el7.x86_64 #1 SMP Wed Sep 21 14:44:14 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux How reproducible:reproducible Steps to Reproduce: The following steps need to be done in dpdk environment. 1.setenforce 1 2.systemctl start openvswitch 3. Actual results: Expected results: Additional info: