Like other services under the protection of SELinux, sVirt uses process-based mechanisms and restrictions to provide an extra layer of security over guest instances. Under typical use, you should not even notice that sVirt is working in the background. This section describes the labeling features of sVirt.
As shown in the following output, when using sVirt, each virtualized guest process is labeled and runs with a dynamically generated level. Each process is isolated from other VMs with different levels:
# ps -eZ | grep qemu
system_u:system_r:svirt_t:s0:c87,c520 27950 ? 00:00:17 qemu-kvm
system_u:system_r:svirt_t:s0:c639,c757 27989 ? 00:00:06 qemu-system-x86
The actual disk images are automatically labeled to match the processes, as shown in the following output:
# ls -lZ /var/lib/libvirt/images/*
system_u:object_r:svirt_image_t:s0:c87,c520 image1
The following table outlines the different labels that can be assigned when using sVirt:
Table 17.1. sVirt labels
| Type |
SELinux Context |
Description |
| Virtualized guest processes |
system_u:system_r:svirt_t:MCS1 |
MCS1 is a randomly selected MCS field. Currently approximately 500,000 labels are supported. |
| Virtualized guest images |
system_u:object_r:svirt_image_t:MCS1 |
Only svirt_t processes with the same MCS fields are able to read/write these image files and devices. |
| Virtualized guest shared read/write content |
system_u:object_r:svirt_image_t:s0 |
All svirt_t processes are allowed to write to the svirt_image_t:s0 files and devices. |
| Virtualized guest shared read only content |
system_u:object_r:svirt_content_t:s0 |
All svirt_t processes are able to read files/devices with this label. |
| Virtualized guest images |
system_u:object_r:virt_content_t:s0 |
System default label used when an image exits. No svirt_t virtual processes are allowed to read files/devices with this label. |
It is also possible to perform static labeling when using sVirt. Static labels allow the administrator to select a specific label, including the MCS/MLS field, for a virtualized guest. Administrators who run statically-labeled virtualized guests are responsible for setting the correct label on the image files. The virtualized guest will always be started with that label, and the sVirt system will never modify the label of a statically-labeled virtual machine's content. This allows the sVirt component to run in an MLS environment. You can also run multiple virtualized guests with different sensitivity levels on a system, depending on your requirements.
