On Thu, Jul 09, 2020 at 11:53:19AM +0200, Milan Zamazal wrote: > Milan Zamazal <mzama...@redhat.com> writes: > > > Daniel P. Berrangé <berra...@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 :|