-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2011 11:01 AM, Daniel J Walsh wrote: > On 04/13/2011 09: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. > >>>> 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). > > > I will open a bugzilla with libvirt to allow the admin to specify a > sensitivity and a range of MCS labels to randomly choose between. This > might be necessary for an other use case that suddenly seems to be > picking up steam, labeled NFS. If Labeled NFS happens we need a way to > make sure two libvirt instances do not choose the same Categories, to > start virtual machines. Thank you very much Daniel. Please, add me to the Bugzilla. > > > Sandbox MCS and SVirt MCS and any other MCS (Coming soon) should still > be isolated by type enforcement rules. - -- Ramon de Carvalho Valle Security Engineer IBM Linux Technology Center rcvalle@xxxxxxxxxxxxxxxxxx http://rcvalle.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2l7IwACgkQkcIYeh81wLlxGQCfQAsutMPdC30n4vohwYWXecrV EFQAoI/FBn2C77vkkkRkePZNN/jntStF =MbKr -----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.
