On Wed, 2011-04-13 at 07:24 -0300, Ramon de Carvalho Valle wrote: > On 04/12/2011 09:50 AM, Stephen Smalley wrote: > > I think this is where Ramon's idea breaks down. The qemu process does > > in fact need access to resources and other services on the host and thus > > making the qemu process run in a context that is completely incomparable > > with the contexts used by host processes and objects will quickly put > > you into a situation where you must grant the qemu process MLS > > overrides. At which point you are no longer deriving much benefit from > > the MLS policy at all. > > > Not exactly. Could you give us an example of such a situation? > > The processes representing virtual machine environments and its > associated resources should belong to the virtualisation sensitivities, > as well as the libvirt daemon. PCI passthrough should be a case a part, > as it needs to be detached from the host anyway--It should be explicitly > allowed and/or have a virtualisation sensitivity, which is the recommended. > > Currently, the libvirt daemon executes with s0-s15:c0.c1023, which is > far more concerning than sv0-sv15:c0.c1023. So where is MLS? If you do a sesearch -A -s qemu_t, you'll see that qemu_t interacts with quite a few types on the host, including both files and processes. And even more so for libvirtd. The more you move into your new sensitivities, the more you'll have to define MLS overrides for more domains. At present, virtd_t (i.e. libvirtd) is given many (all?) MLS overrides, which is unsurprising since it is expected to create and manage VMs at any level. But qemu_t (i.e. the qemu process representing the individual VM) is not given such MLS overrides, nor should it, as that would allow to escape the confines of its level/range. > So far we have been discussing how to accomplish what was proposed using > costly non standard methods and workarounds without considering the > benefits of a far more elegant solution, which until now does not seem > to have any downsides--despite the development effort. I can't quite see how your approach is cleaner than just using separate categories. Same effect - by allocating a dedicated category to the VMs and another to the host, you end up with incomparable levels and thus will achieve automatic isolation except where explicitly overridden using the type attributes for MLS overrides. Adding another incomparable set of sensitivities puts us outside the scope of any evaluated or even published security model. Now something that has been suggested in the past would be adding another level/range component to the security context for use by a Biba-like integrity model. That might be interesting, but would obviously require quite a few changes on both the kernel and userland side. It would also require resolving the unfortunate ambiguity in the current security context format. > We must consider that virtualisation is not something that is invented > every decade, and how much more we have the operating system and its > security mechanisms aware of it, is to be prepared for what comes next. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
