-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2011 02:32 PM, Ramon de Carvalho Valle wrote: > On 04/13/2011 10:51 AM, Stephen Smalley wrote: >> 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. > Not if these objects also have the virtualisation sensitivities assigned > to them (i.e. s0,sv0). > > >>>> 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. > Well, I think this is what will happen in the end of this discussion anyway. > > >>>> 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). > This still implies an hierarchy between these multiple set of > sensitivities and categories. > > > - -- 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. Open Bugzilla for libvirt to accept a range of categories and a sensitivity level to launch virtual machines. https://bugzilla.redhat.com/show_bug.cgi?id=696292 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2l9NQACgkQrlYvE4MpobNyggCfQ6snx0DNhz216cCqP8s9BiCk tAYAn1vGpsLOyQAOO7m64MlzNMBSjOqA =6HKl -----END PGP SIGNATURE----- -- 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.
