James Morris wrote:
This is a request for comments on the initial prototype release of sVirt, a project to add security labeling support to Linux-based virtualization.
Project page: http://www.selinuxproject.org/page/SVirt
Previous libvirt discussions:
High-level requirements: https://www.redhat.com/archives/libvir-list/2008-August/msg00255.html
XML security labels: https://www.redhat.com/archives/libvir-list/2008-August/msg00740.html
A patch for libvirt is attached; and also included in a release tarball at http://namei.org/svirt/. See 'readme.txt' there for more details on building and running the code.
The purpose of this release is to establish a proof of concept of applying security labels to VMs, and for discussion of the underlying technical approach.
With this release, it is possible to define a security label for a kvm/qemu domain in its XML configuration ('virsh edit'), launch the domain and have it transition to the specified security label ('virsh start'), then query the security label of the running domain ('virsh dominfo').
The following changes were made to libvirt:
1. Implementing a pluggable security label driver framework;
2. Implementing an SELinux security label driver for (1);
3. Wiring the security label framework into the Qemu driver;
4. Implementing basic libvirt API calls for initializing the driver, and getting/setting domain security labels;
5. Extending the domain XML configuration to include security labels;
6. Adding domain security label display/edit/dump support to virsh.
One of the design principles I've followed with this is to reduce or eliminate configuration wherever possible. If a variety of security labeling drivers are present, libvirtd automatically detects which one to enable and enables it. e.g. if SELinux is enabled on the system, the SELinux labeling driver is enabled automatically when livbirtd starts.
Another is to treat security labels as opaque unless they're actually being used for security purposes (e.g. to launch the domain). So, virsh and the domain configuration code currently do not need to semantically interpet security labels, just understand their format. This should suit the initial simple goal of isolated domains, which only requires security labels to be distinct.
The domain security label configuration format is as follows:
# virsh dumpxml sys1 <domain> .... <seclabel model='selinux'> <label>system_u:system_r:virtd_t:s0</label> <policytype>targeted</policytype> </seclabel> </domain>
It's possible to query the security label of a running domain via virsh:
# virsh dominfo sys1 Id: 1 Name: sys1 UUID: fa3c8e06-0877-2a08-06fd-f2479b7bacb4 OS Type: hvm State: running CPU(s): 1 CPU time: 11.4s Max memory: 524288 kB Used memory: 524288 kB Autostart: disable Security label: system_u:system_r:virtd_t:s0 (selinux/targeted/enforcing)
The security label is deterimed via the new virDomainGetSecLabel() API method, which is transported over RPC to the backend driver (qemu in this case), and is entirely independent of the local security model, if any. e.g. this command could be run remotely from an entirely different platform: you just see what's happening on the remote system, as with other attributes of the domain.
Feedback on the design thus far is sought before proceeding to more comprehensive integration.
In particular, I'd be interested in any thoughts on the placement of the security labeling driver within libvirt, as this seems to be the most critical architectural issue (I've already refactored this aspect once).
Currently, the idea is to attach the security labeling driver to the virt driver, rather than implement it independently as a top-level component as in the case of other types of drivers (e.g. storage). This is because process-based security labeling is highly dependent on the kind of virtualization in use, and may not make sense at all in some cases (e.g. when using a non-Linux hypervisor, or containers).
In the case of qemu, a security labeling driver is added to qemud:
@@ -63,6 +64,7 @@ struct qemud_driver { char *vncListen;
virCapsPtr caps; + virSecLabelDriverPtr secLabelDriver; };
and then initialized during qemud startup from qemudSecLabelInit().
During initialization, any available security labeling drivers are probed, and the first one which thinks it should be used is installed. Top-level libvirt API calls are then dispatched to the active security labeling driver via the backend virt driver, as necessary.
Note that the security labeling framework in this release is always built-in -- it can be made a compile-time option later if desired.
Requirements not yet addressed include: - Labeling of resources and generally comprehensive labeling management - Automatic labeling (e.g. for the simple isolation use-case) - Integration of labeling support into higher-level management tools such as virt-manager - Integration with the audit subsystem to help with administration and debugging - Domain of interpretation (DOI) checking/translation - Python bindings
As mentioned, the goal at this stage is to get feedback on the underlying design: comments welcome!
- James
Why do we care about the policy type? Policy type is a fairly meaningless object. If you are trying to figure out if the host machine is valid to run a virtual machine you should just check whether the type is valid on the machine, That way if I define minimum policy with virt support on one host and targeted policy with virt support on another machine, both would work. Finally I think it might be ok for the administrator to request that this virtual machine would only run on a machine with SELinux in enforcing mode. For example if you had a fairly untrusted virtual machine you would want to ensure that the machine was enforcing SELinux before it got started.