Re: SELinux mixed/virtualisation policy

[Daniel J Walsh <dwalsh@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


Sandbox MCS and SVirt MCS and any other MCS (Coming soon) should still
be isolated by type enforcement rules.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2lrL8ACgkQrlYvE4MpobPTaQCfSiOElDU7Ncpr3RahZIAMqnxG
N5IAnjwV7vn+FRysCBY6KWV72KneHvj2
=fDFD
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.