-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. > - -- 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) iEYEARECAAYFAk2l7FMACgkQkcIYeh81wLmJ+gCePDH3/jupKn8vKwKGBO+Q29rS R1UAn1Z7ijj/t+24eZrqgg0eaSjhOEha =kzxp -----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.
