Two small improvements to sVirt guest configuration flexibility with KVM+libvirt

sVirt has been available in the libvirt KVM driver for a few years now, both for SELinux and more recently for AppArmour. When using it with SELinux there has been a choice of two different configurations

Dynamic configuration

libvirt takes the default base label (“system_u:system_r:svirt_t:s0”), generates a unique MCS label for the guest (“c123,c465”) and combines them to form the complete security label for the virtual machine process. libvirt takes the same MCS label and combines it with the default image base label (“system_u:system_r:svirt_image_t:s0”) to form the image label. libvirt will then automatically apply the image label to all host OS files that the VM is required to access. These can be disk images, disk devices, PCI devices (we label the corresponding sysfs files), USB devices (we label the /dev/bus/usb files), kernel/initrd files, and a few more things. When the VM shuts down again, we reverse the labelling. This mode was originally intended for general usage where the management application is not aware of the existence of sVirt.

Static configuration

The guest XML provides the full security label, including the MCS part. libvirt simply assigns this security label to the virtual machine process without trying to alter/interpret it any further. libvirt does not change the labels of any files on disk. The administrator/application using libvirt, is expected to have done all the resource file labelling ahead of time. This mode was originally intended for locked down MLS environments, where even libvirtd itself is not trusted to perform relabelling

These two configurations have worked well enough for the two uses cases they were designed to satisfy. As sVirt has become an accepted part of the libvirt/KVM ecosystem, application developers have started wanting todo more advances things which are currently harder than they should be. In particular some applications want to have full control over the security label generation (eg to ensure cluster-wide unique labels, instead of per-host uniqueness), but still want libvirt to take care of resource relabelling. This is sort of a hybrid between our static & dynamic configuration. Other applications would like to be able to choose a different base label (“system_u:system_r:svirt_custom_t:s0”) but still have libvirt assign the MCS suffix and perform relabelling. This is another variant on dynamic labelling. To satisfy these use cases we have extended the syntax for sVirt labelling in recent libvirt. The “seclabel” element gained a ‘relabel’ attribute to control whether resource relabelling is attempted. A new “baselabel” element was introduced to override the default base security label in dynamic mode. So there are now 4 possible styles of configuration:

• Dynamic configuration (the default out of the box usage)
  

  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c192,c392</label>                  (output only element)
    <imagelabel>system_u:object_r:svirt_image_t:s0:c192,c392</imagelabel>  (output only element)
  </seclabel>

• Dynamic configuration, with base label

  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <baselabel>system_u:system_r:svirt_custom_t:s0</baselabel>
    <label>system_u:system_r:svirt_custom_t:s0:c192,c392</label>           (output only element)
    <imagelabel>system_u:object_r:svirt_image_t:s0:c192,c392</imagelabel>  (output only element)
  </seclabel>

• Static configuration, no resource labelling (primarily for MLS/strictly controlled environments)
  

  <seclabel type='static' model='selinux' relabel='no'>
    <label>system_u:system_r:svirt_custom_t:s0:c192,c392</label>
  </seclabel>

• Static configuration, with dynamic resource labelling

  <seclabel type='static' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_custom_t:s0:c192,c392</label>
  </seclabel>