sVirt

[Daniel J Walsh]

On 07/06/2009 12:31 PM, Stephen Smalley wrote:
> On Mon, 2009-07-06 at 11:12 -0400, Gene Czarcinski wrote:
>> On Monday 06 July 2009 09:29:25 Stephen Smalley wrote:
>>>> I believe that changing any file context should not be done.  Depend on
>>>> the rules in the security policy or any added with semanage apply.  And
>>>> then let something like public_content_t and public_content_rw_t be OK
>>>> too.
>>>>
>>>> Mmmm, this makes so much sense that I think I will bugzilla this.
>>> The reason that it presently relabels the disk image is that it is
>>> auto-generating a unique security context (unique category pair) for
>>> each VM, and then assigning that category pair to both the qemu-kvm
>>> process and to the disk image to isolate instances from one another.
>> OK does this "unique security context" protect guests from each other?
> 
> It provides some degree of isolation between them, yes.  By default, the
> TE policy is being used to protect the host from the guests (by
> restricting what types are accessible to svirt_t), and the MCS policy is
> being used to isolate the guests from one another (by using unique
> category sets for each guest).
> 
>> I do not understand what is being protected and who are we protecting from. 
>> [with respect to ISO image files and other shared files]
>>
>> I am not talking about a guest's virtual disk in /var/lib/libvirt/images (or 
>> whatever).
>>
>> Regardless, I do NOT believe that sVirt should be changing file contexts.  The 
>> system (security?) administrator should be controlling what contexts a file has 
>> ... it should not be happening under the sVirt covers.  This is especially 
>> true when it effects other processes (my httpd example).
>>
>> ISO image files should be sharable between guests as well as other processes on 
>> the system with a common file context.
>>
>> Setting the file context also causes other problems when the ISO image exists 
>> in a read-only file system.
> 
> There are definitely situations where relabeling should not happen.  But
> the sVirt designers wanted some default protection out of the box,
> without requiring manual configuration by an admin.  Thus automatic
> generation of MCS category pairs for each guest, with those categories
> applied to the process and to the virtual disk image.
> 
>>> There is also a static configuration option where you can specify the
>>> desired context for the VM, in which case it shouldn't relabel the disk
>>> image.
>> Is there additional information somewhere about using this "static 
>> configuration option"?
> 
> First, you need to use virsh edit to add/replace the seclabel entry
> with something like this:
>   <seclabel type='static' model='selinux'>
>     <label>system_u:system_r:svirt_t:s0:c1</label>
>   </seclabel>
> 
> Note the type='static' part, which prevents libvirt from clobbering it
> later with a dynamically generated context.
> 
> Then you need to manually label the image file - it won't do that for
> you once you've defined a static label, e.g.:
> chcon
> system_u:object_r:svirt_image_t:s0:c1 /var/lib/libvirt/images/vm1.img
> 
I also have made a patch to virt-manager to do this from the GUI, although it has not been merged yet into Rawhide.