NVDIMM in devdax mode and SELinux (was: Two questions about NVDIMM devices)

[Daniel P. Berrangé]

On Thu, Jul 09, 2020 at 11:53:19AM +0200, Milan Zamazal wrote:
> Milan Zamazal <mzamazal at redhat.com> writes:
> 
> > Daniel P. Berrangé <berrange at redhat.com> writes:
> >
> >> On Thu, Jul 02, 2020 at 01:21:15PM +0200, Milan Zamazal wrote:
> >>> The second problem is that a VM fails to start with a backing NVDIMM in
> >>> devdax mode due to SELinux preventing access to the /dev/dax* device (it
> >>> doesn't happen with any other NVDIMM modes).  Who should be responsible
> >>> for handling the SELinux label appropriately in that case?  libvirt, the
> >>> system administrator, anybody else?  Using <seclabel> in NVDIMM's source
> >>> doesn't seem to be accepted by the domain XML schema.
> >>
> >> The expectation is that out of the box SELinux will "just work". So
> >> anything that is broken is a bug in either libvirt or selinux policy.
> >>
> >> There is no expectation/requirement to use <seclabel> unless you want
> >> to setup non-default behaviour which isn't the case here.
> >>
> >> IOW this sounds like a genuine bug.
> >
> > OK, I'll try to find out what and where is the problem exactly.
> 
> The problem apparently is that /dev/dax* is a character device rather
> than a block device (such as /dev/pmem*), which is not expected by
> SELinux policy rules.
> 
> This is an NVDIMM in fsdax mode:
> 
>   # ls -lZ /dev/pmem0
>   brw-rw----. 1 root disk system_u:object_r:device_t:s0 259, 0 Jul  9 11:39 /dev/pmem0
> 
> This is the same NVDIMM reconfigured as devdax:
> 
>   # 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
> 
> (Unix permissions are different, but when I change them to `disk' group
> and 660, the same problem still occurs.)
> 
> audit.log reports the following when starting a VM with an NVDIMM device
> in devdax mode:
> 
>   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
> 
> Indeed, svirt_t map access to svirt_image_t is allowed only for files
> and block 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;
> 
> What to do about it?  Do I handle the NVDIMM in a wrong way or should
> sVirt policies be fixed?

File a BZ against the policy as this looks like a valid use case


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|