Bug 1855336 - sVirt policy doesn't allow passing host NVDIMM in devdax mode to a VM
Summary: sVirt policy doesn't allow passing host NVDIMM in devdax mode to a VM
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.2
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 1892805
TreeView+ depends on / blocked
 
Reported: 2020-07-09 15:10 UTC by Milan Zamazal
Modified: 2021-07-01 14:13 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1361718 1 None None None 2021-05-05 09:24:32 UTC

Internal Links: 1879175

Description Milan Zamazal 2020-07-09 15:10:53 UTC
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:

Comment 3 Milan Zamazal 2021-03-17 13:04:36 UTC
Hi Zdenek, what are the plans regarding this bug? When can we expect a fix?

Comment 4 Zdenek Pytela 2021-03-17 14:41:00 UTC
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@linux.microsoft.com>
Date:   Fri May 31 13:44:49 2019 -0400

    devices: Add type for /dev/daxX.Y.
    
    Signed-off-by: Chris PeBenito <chpebeni@linux.microsoft.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.*
 #

Comment 5 Milan Zamazal 2021-03-17 19:20:41 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.