Milan Zamazal <mzamazal@xxxxxxxxxx> writes:
> Daniel P. Berrangé <berrange@xxxxxxxxxx> 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?
Thanks,
Milan
