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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list