Bug 1855336
| Summary: | sVirt policy doesn't allow passing host NVDIMM in devdax mode to a VM | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Milan Zamazal <mzamazal> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED WONTFIX | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.2 | CC: | emarcus, lvrabec, mmalik, plautrba, ssekidde, zpytela |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-01-09 07:26:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1892805 | ||
Hi Zdenek, what are the plans regarding this bug? When can we expect a fix? Milane,
This bug has unfortunately not been fully acknowledged by the subsystem to be resolved during the RHEL 8.4 development and testing phase, so it will be evaluated for inclusion into the next minor product update.
I just wonder if it is at all correct that device files have the svirt_image_t type and not e. g. dax_device_t.
I see the dax devices added to refpolicy:
commit 666b744714a08a142ce38d6f9df378bdc71c69c8
Author: Chris PeBenito <chpebeni.com>
Date: Fri May 31 13:44:49 2019 -0400
devices: Add type for /dev/daxX.Y.
Signed-off-by: Chris PeBenito <chpebeni.com>
diff --git a/policy/modules/kernel/devices.fc b/policy/modules/kernel/devices.fc
index 3b9be43f9..bdff6b1a4 100644
--- a/policy/modules/kernel/devices.fc
+++ b/policy/modules/kernel/devices.fc
@@ -21,6 +21,7 @@
/dev/controlD64 -c gen_context(system_u:object_r:xserver_misc_device_t,s0)
/dev/crash -c gen_context(system_u:object_r:crash_device_t,mls_systemhigh)
/dev/dahdi/.* -c gen_context(system_u:object_r:sound_device_t,s0)
+/dev/dax[0-9]\.[0-9] -c gen_context(system_u:object_r:dax_device_t,mls_systemhigh)
/dev/dmfm -c gen_context(system_u:object_r:sound_device_t,s0)
/dev/dmmidi.* -c gen_context(system_u:object_r:sound_device_t,s0)
/dev/dsp.* -c gen_context(system_u:object_r:sound_device_t,s0)
diff --git a/policy/modules/kernel/devices.te b/policy/modules/kernel/devices.te
index a0331212c..88a4246e8 100644
--- a/policy/modules/kernel/devices.te
+++ b/policy/modules/kernel/devices.te
@@ -82,6 +82,12 @@ dev_node(crash_device_t)
type crypt_device_t;
dev_node(crypt_device_t)
+#
+# Type for /dev/dax*.*
+#
+type dax_device_t;
+dev_node(dax_device_t)
+
#
# dlm_misc_device_t is the type of /dev/misc/dlm.*
#
(In reply to Zdenek Pytela from comment #4) > This bug has unfortunately not been fully acknowledged by the subsystem to > be resolved during the RHEL 8.4 development and testing phase, so it will be > evaluated for inclusion into the next minor product update. OK, thank you for info. > I just wonder if it is at all correct that device files have the > svirt_image_t type and not e. g. dax_device_t. > > I see the dax devices added to refpolicy: Before starting the VM, the device has device_t type on my RHEL 8.3, no idea why it's not dax_device_t. I guess it gets temporarily (for the time of the VM run) relabeled to svirt_image_t as part of VM start preparation by libvirt. Which may be what QEMU expects for a backing device/image. But those are just my speculations, libvirt guys should know better. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. |
Description of problem: When starting a virtual machine, a host NVDIMM device can be used as a backing device for a virtual NVDIMM device used in the virtual machine. NVDIMM devices can be configured to different modes. In most of the modes, e.g. fsdax, they appear as block devices in the system: # ls -lZ /dev/pmem0 brw-rw----. 1 root disk system_u:object_r:device_t:s0 259, 0 Jul 9 11:39 /dev/pmem0 But in devdax mode, they appear as character devices: # ls -lZ /dev/dax0.0 crw-------. 1 root root system_u:object_r:device_t:s0 252, 5 Jul 9 11:43 /dev/dax0.0 When an NVDIMM device in devdax mode is added as a backing device to a virtual NVDIMM module of a virtual machine, SELinux prevents access to the device and the virtual machine won't start: type=AVC msg=audit(1594144691.758:913): avc: denied { map } for pid=21659 comm="qemu-kvm" path="/dev/dax0.0" dev="tmpfs" ino=1521557 scontext=system_u:system_r:svirt_t:s0:c216,c981 tcontext=system_u:object_r:svirt_image_t:s0:c216,c981 tclass=chr_file permissive=0 type=AVC msg=audit(1594144691.758:914): avc: denied { map } for pid=21659 comm="qemu-kvm" path="/dev/dax0.0" dev="tmpfs" ino=1521557 scontext=system_u:system_r:svirt_t:s0:c216,c981 tcontext=system_u:object_r:svirt_image_t:s0:c216,c981 tclass=chr_file permissive=0 The problem is that SELinux permits svirt_t map access to svirt_image_t only for files and block devices, and not character devices: # sesearch -A -p map -s svirt_t -t svirt_image_t ... allow svirt_t svirt_image_t:blk_file map; allow svirt_t svirt_image_t:file map; Version-Release number of selected component (if applicable): 3.14.3-41.el8_2.4 How reproducible: 100% Steps to Reproduce: Run a virtual machine with an NVDIMM device using a host NVDIMM device in devdax mode as the backing device. The virtual NVDIMM device can be defined in libvirt domain XML, e.g. <memory access="shared" model="nvdimm"> <source> <path>/dev/dax0.0</path> <pmem/> </source> <target> <size unit="KiB">4851712</size> <node>0</node> </target> </memory> or on QEMU command line, e.g. -object memory-backend-file,id=memua-9275560b-0242-4df7-9a22-2a336c78d0ca,prealloc=yes,mem-path=/dev/dax0.0,share=yes,size=4968153088,align=2097152,pmem=on Actual results: The VM fails to start due to the inaccessible NVDIMM device. Expected results: The VM can start with the device. Additional info: