Hi there,
Quoting https://libvirt.org/drvqemu.html
"Disks that are marked as <shared> will get a generic label system_u:system_r:svirt_image_t:s0 allowing all guests read/write access them"
The problem now is that the shared disks can potentially being accessed by other VMs which is not really nice.
Is it safe to remove the shared parameter in the libvirt config and use static labeling instead?
Thanks,
Luc
On Thu, Aug 27, 2015 at 09:37:13AM +0200, Luc de Louw wrote:
Hi there,
Quoting https://libvirt.org/drvqemu.html
"Disks that are marked as <shared> will get a generic label system_u:system_r:svirt_image_t:s0 allowing all guests read/write access them"
The problem now is that the shared disks can potentially being accessed by other VMs which is not really nice.
Is it safe to remove the shared parameter in the libvirt config and use static labeling instead?
NB, <shared> is intended for the case where multiple VMs are accessing the same disk volume. So whatever label is used needs to allow multiple VMs to access it. What we really need is some kind of way to have group labels - eg a way to say VMs X, Y & Z can access the disk, but not VMs A, B & C, etc. AFAIK, there's no easy way to achieve this with SELinux MCS levels, hence why libvirt has to just use a generic allow-all label for shared disks.
You can provide custom labels for any disks on a per-disk basis using the <seclabel> XML element inside the <source> tag for the disk in question.
Regards, Daniel
On 08/27/2015 03:37 AM, Luc de Louw wrote:
Hi there,
Quoting https://libvirt.org/drvqemu.html
"Disks that are marked as <shared> will get a generic label system_u:system_r:svirt_image_t:s0 allowing all guests read/write access them"
The problem now is that the shared disks can potentially being accessed by other VMs which is not really nice.
Is it safe to remove the shared parameter in the libvirt config and use static labeling instead?
Thanks,
Luc
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
From an SELinux point of view, it should work. As long as the label is
svirt_image_t:s0, SELinux will not prevent any processes running as svirt_t (guests qemu processes) from reading and writing the content.
selinux@lists.fedoraproject.org