On Wed, 2011-04-13 at 10:03 -0300, Ramon de Carvalho Valle wrote: > On 04/13/2011 09:19 AM, Stephen Smalley wrote: > > 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. > Actually, processes representing virtual machine environments--when > initiated by libvirt--execute with svirt_t and not qemu_t, which also > belongs to virt_domain type attribute. So why the virt_domain rules > could not be moved to the virtualisation sensitivities? The same is true for svirt_t - if you look at the policy, you'll see that it interacts with various host processes and accesses various host files. You can't push all of those into your new sensitivities, and thus the end result will be that you'll have to allow interactions between the "regular" sensitivities and the "virtualization" sensitivities, thereby adding more exceptions to the MLS constraints. > > 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. > How dynamic labeling is supposed to work with this approach? We will > need a standard set of categories defined to libvirt use. Yes, you just need to standardize some allocation for libvirt, which realistically ought to be done anyway, since we already have other users of categories like sandbox. > > 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. > Please, correct if I am wrong, but from what I understand adding another > level and range component will just add another level of hierarchy for > multiple set of sensitivities and categories (i.e. > s0-s15:s0-s15:c0.c1023 or even s0-s15:c0.c1023:s0-s15:c0.c1023). So the > virtualised sensitivities should be below or above the standard > sensitivities in this new level and range component? Having another level/range component (or more generally, an extensible list of level/range components) would more easily delineate multiple uses of the level/range for different purposes. So you could have simultaneous MLS+libvirt dynamic labeling without needing to worry about allocation of categories between them. Or you could have simultaneous MLS+Biba. Or all three (if extensible). -- 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.
