Re: SELinux mixed/virtualisation policy

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

-----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@tycho.nsa.gov
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.