Is this something that svirt_t processes should be able to access (perhaps guarded with a new sebool) or should libvirt somehow relabel the file? I don't know enough about Infiniband and RDMA, but relabeling the file seems wrong to me because QEMU may not be the only user of RDMA.

Mirek Grepl confirmed a new sebool would be a better solution; moving to selinux-policy.

I am also not sure about /dev/infiniband purpose. I need to do some research.

Should we label FD?

(In reply to Miroslav Grepl from comment #4)
> I am also not sure about /dev/infiniband purpose. I need to do some research.
> 
> Should we label FD?

Infiniband is hardware that provides an RDMA transport between hosts.  As for the meaning of each of the files in /dev/inifiniband I don't know; dledford is a good contact for the details of how it's supposed to work.

All of the infiniband files are basically command pipes.  You use the file to send commands to kernel modules.  The permissions on the files are intentionally.  Those with world writable permissions accept commands that any user is allowed to send.  Those with root only write permissions are files that accept privileged commands.  For the purposes of live migration, it would make sense that qemu would have access to the world writable files.  The root only writable files are not needed by qemu/kvm and would present a security risk if it were allowed to access them freely.

It would probably be best if we split the infiniband SElinux type into two types infiniband_user_t and infiniband_mgmt_t.  The world writable files would be infiniband_user_t and access should be freely allowed from other selinux contexts.  The infiniband_mgmt_t should be limited to certain applications (I can provide a list if needed).

Moving to libvirt to have a discussion about possible labeling.

The labeling sounds OK to me, but IIUC the labeling will be static and not managed by libvirt. And libvirt will not even need to know what the labeling is. That said it's really up to infiniband and selinux-policy guys to discuss and implement the right labeling.

(In reply to Doug Ledford from comment #9)
> All of the infiniband files are basically command pipes.  You use the file
> to send commands to kernel modules.  The permissions on the files are
> intentionally.  Those with world writable permissions accept commands that
> any user is allowed to send.  Those with root only write permissions are
> files that accept privileged commands.  For the purposes of live migration,
> it would make sense that qemu would have access to the world writable files.
> The root only writable files are not needed by qemu/kvm and would present a
> security risk if it were allowed to access them freely.
> 
> It would probably be best if we split the infiniband SElinux type into two
> types infiniband_user_t and infiniband_mgmt_t.
Could you define which devices should have user and which mgmt type? 
[root@virtlab414 ~]# ls -lZ /dev/infiniband/
crw-------. root root system_u:object_r:infiniband_device_t:s0 issm0
crw-------. root root system_u:object_r:infiniband_device_t:s0 issm1
crw-rw-rw-. root root system_u:object_r:infiniband_device_t:s0 rdma_cm
crw-rw-rw-. root root system_u:object_r:infiniband_device_t:s0 ucm0
crw-------. root root system_u:object_r:infiniband_device_t:s0 umad0
crw-------. root root system_u:object_r:infiniband_device_t:s0 umad1
crw-rw-rw-. root root system_u:object_r:infiniband_device_t:s0 uverbs0



  The world writable files
> would be infiniband_user_t and access should be freely allowed from other
> selinux contexts.  The infiniband_mgmt_t should be limited to certain
> applications (I can provide a list if needed).
Could you provide a list? 

Thank you.

Hi dledford, 

Could you check comment12 ? 

Thank you.

I already answered which files should have which SELinux types:

world writeable (mode 666) files should have normal IB type
root writeable (mode 600) files should have IB mgmt type

Apps that will need IB mgmt type (at a minimum, I might have missed some):

From the opensm package:

/usr/sbin/opensm
/usr/sbin/osmtest

from ibutils:

/usr/bin/*

from ibacm:

/usr/bin/*
/usr/sbin/*

from infiniband-diags:

/usr/sbin/*

from srptools:

/usr/sbin/srp_daemon
/usr/sbin/ibsrpdm

from perftest:

unknown, will need to test it and see what breaks without having mgmt type and decide if we want to give mgmt type or keep the breakage

from mvapich2:

ditto perftest

opa-basic-tools:

unknown, will have to test and make recommendations

opa-address-resolution:

won't need a change, it will get it's type from ibacm as it is just a plugin library that ibacm uses

opa-fm:

will need testing to confirm, but I suspect it needs /usr/sbin/*, /usr/lib/opa-fm/bin/*, /usr/lib/opa-fm/runtime/*

That's the rough list.  It might need additional tweaks based on testing, and even though I think I have all of the umad using apps installed at the moment, I could have missed some.

I split the devices as was mentioned in comment14. Can I make scratch builds for testing and collecting some AVCs?

Attaching scratch builds:

http://download.eng.brq.redhat.com/scratch/lvrabec/scratch_selinux_policy_infiniband/

Could somebody test it and collect AVC denials? 

Thank you.

Hi Lukas,
  It still seems to be unhappy with your packages;

(again this is from the destination side):

type=AVC msg=audit(1467889442.717:292): avc:  denied  { read write } for  pid=3385 comm="qemu-kvm" name="rdma_cm" dev="devtmpfs" ino=18626 scontext=system_u:system_r:svirt_t:s0:c333,c758 tcontext=system_u:object_r:infiniband_device_t:s0 tclass=chr_file
type=AVC msg=audit(1467889442.717:293): avc:  denied  { read write } for  pid=3385 comm="qemu-kvm" name="rdma_cm" dev="devtmpfs" ino=18626 scontext=system_u:system_r:svirt_t:s0:c333,c758 tcontext=system_u:object_r:infiniband_device_t:s0 tclass=chr_file

qemu-kvm-rhev-2.6.0-9.el7.x86_64
libvirt-1.3.5-1.el7.x86_64
selinux-policy-3.13.1-82.el7.5.noarch
selinux-policy-targeted-3.13.1-82.el7.5.noarch

[root@virtlab403 ~]# ls -lZ /dev/infiniband/
crw-------. root root system_u:object_r:infiniband_mgmt_device_t:s0 issm0
crw-------. root root system_u:object_r:infiniband_mgmt_device_t:s0 issm1
crw-rw-rw-. root root system_u:object_r:infiniband_device_t:s0 rdma_cm
crw-rw-rw-. root root system_u:object_r:infiniband_device_t:s0 ucm0
crw-------. root root system_u:object_r:infiniband_mgmt_device_t:s0 umad0
crw-------. root root system_u:object_r:infiniband_mgmt_device_t:s0 umad1
crw-rw-rw-. root root system_u:object_r:infiniband_device_t:s0 uverbs0

Hi, 

These AVCs are expected, it's easy fix. I see fixed labeling here. That's good. I'm going to fix these AVCs asap.

Thank you for testing.

hi, 

Is there any other issues with this fix selinux build? Does thie bug can be tested and verified now.
We are verifying one libvirt testonly bug 1331802, which is depend on this selinux bug. If no other issues for this selinux bug, we'd like to change our libvirt bug to verify status. Thanks.
Following is the verify result and steps for your reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1331802#c2

Functional testing verified the version selinux-policy-3.13.1-86.el7 has necessary rules.

Moving to verified.

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, 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://rhn.redhat.com/errata/RHBA-2016-2283.html