Summary: | VFIO (direct device access) with libvirt and selinux has policy gaps, proposed fix | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Wetzel <alexander> |
Component: | SELinux | Assignee: | SE Linux Bugs <selinux> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | sec-policy r10 | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
selinux-base patch to add vfio
selinux-virt patch selinux-base patch to add vfio |
Created attachment 384676 [details, diff]
selinux-virt patch
Created attachment 384678 [details, diff]
selinux-base patch to add vfio
removed reference to devices.te.orig.
Are sclp and vmcp really also supported to be vfio devices? The /dev/vfio/* is pretty obvious, but sclp and vmcp seem to be s390 related drivers? I would like to directly upstream these patches, but then I need to know for sure that sclp and vmcp truly need to be labeled as vfio_device_t. > Are sclp and vmcp really also supported to be vfio devices? The /dev/vfio/* > is pretty obvious, but sclp and vmcp seem to be s390 related drivers? I assumed that these are providing the same funcion for other systems/plattforms and did just copied that from the Centos policy. (I do not have either on my system, of course) find /dev/vfio/ /dev/sclp* /dev/vmcp* /dev/vfio/ /dev/vfio/1 /dev/vfio/vfio find: `/dev/sclp*': No such file or directory find: `/dev/vmcp*': No such file or directory Looking at the following links that seems to be wrong: http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_vmcp_cmd.html http://www-01.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_r_lmtkernelparameter.html?lang=en https://lkml.org/lkml/2014/10/21/358 Since the last link seems to show that s390 is also (on the way to) using vfio it's very unlikely that the other files should be vfio labeled. > > I would like to directly upstream these patches, but then I need to know for > sure that sclp and vmcp truly need to be labeled as vfio_device_t. If you need some tests I'm happy to help out. It might be better if this is sent to upstream first. Do you want to send it to the refpol list? I dont use pci pass through so I cant test properly. Sure, I can do that. I've just "sunset" my virtual system needing that this vfio patch this week, but should be no problem to setup something similar. I'll cleanup the patch, test it and then send it for review to the SELinux refpol mailing list. (May take some time, though) A modified version has been merged in upstream, this bug here can be closed. I'll close it once I pull it into our repo and it gets stabilized. in master now r10 released in ~arch stable now |
Created attachment 384674 [details, diff] selinux-base patch to add vfio I've got pci device pass through to a kvm guest with libvirt working with selinux and (tried) to implement this correctly within Gentoo. (The documentation in the gentoo wiki is really very useful, thank you very much for making that available!) I've only tested it with an PCIe ISDN card but that is now working perfectly. This needs two patches, one for the "selinux-base" (adding vfio) and another to "selinux-virt" (defining the rules). Applied as ebuild patches they provide a new selinux boolean "virt_use_vfio" which when set will allow libvirt to make use of vfio for guests. As an overview, this are the rules needed - assuming vfio is available - and (parts) of the error messages I get when the corresponding rule is missing. (The virtual system is not powering up for all errors): allow virtd_t self:process setrlimit; # error: internal error: Process exited prior to exec: libvirt: error : cannot limit locked memory to 5368709120: Permission denied allow virtd_t self:capability sys_resource; # error: internal error: Process exited prior to exec: libvirt: error : cannot limit locked memory to 5368709120: Operation not permitted allow virtd_t svirt_t:process rlimitinh; # vfio_dma_map(0x121e2a5fa0, 0x0, 0xa0000, 0x2c6b4000000) = -12 (Cannot allocate memory) allow svirt_t vfio_device_t:chr_file { read write open ioctl }; # vfio: failed to open /dev/vfio/vfio: Permission denied allow virtd_t vfio_device_t:chr_file { relabelfrom setattr }; # error: unable to set user and group to '77:77' on '/dev/vfio/1': Permission denied Some remarks about the patches: "selinux-base": The core of this patch was extracted from Centos, selinux-policy-3.12.1-153.el7_0.10.src.rpm. The interfaces provided for vfio by Centos are useless and could be removed for this use case, but I'm not sure if that is desired and so they are included in the patch. I ended up with adding two new interface definitions really get the minimum rights. (The naming is probably off and has to be changed): "dev_rw_vfio_dev_min" and "dev_trans_vfio_dev". "selinux-virt": This is just a minor change defining the new selinux boolean to add the rules from the overview, with the help of the two new interface calls in "selinux-base"