Re: [RFC][PATCH 00/01]qemu VM entrypoints

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

David Windsor wrote:
> On 7/21/07 2:21 AM, "Avi Kivity" <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>
>   
>> Anthony Liguori wrote:
>>     
>>> James Morris wrote:
>>>   
>>>       
>>>> On Fri, 20 Jul 2007, Daniel P. Berrange wrote:
>>>>
>>>>   
>>>>     
>>>>         
>>>>> It could be - if your put the policy at the control API layer instead of
>>>>> in QEMU itself.
>>>>>     
>>>>>       
>>>>>           
>>>> Then you can bypass MAC security by invoking qemu directly.
>>>>   
>>>>     
>>>>         
>>> You can bypass MAC security by writing your own binary that uses the KVM
>>> kernel interfaces.
>>>
>>>   
>>>       
>> I guess modifying qemu makes sense if the modification gives you *more*
>> permissions.
>>
>> i.e. you start out just with the ability to access the disk image, and
>> then you transition to a new domain that allows you to access some network.
>>
>>
>> Is that what is intended here?
>>     
>
> The intent here is to provide some mechanism for a policy-driven transition
> to occur when loading a virtual disk.  So, an administrator would write
> policy for say, a topsecret_vm_t domain, in which the top secret VM can run.
> All access requests from this VM would have a source type of topsecret_vm_t
> on the host machine.  The virtual disk, labeled perhaps as topsecret_disk_t,
> would need to be authorized in policy to be an entrypoint into the
> topsecret_vm_t domain.  This patch proposes a mechanism that allows us to
> provide policy driven controls both over which files can be used as a disk
> image, and to which domain a qemu process will transition after loading the
> disk image.  
>   

Can you already write an selinux policy that changes the label of a 
process when it open()s a different file?

Regards,

Anthony Liguori

> Originally, I thought qemu was the proper place for this type of an
> enforcement hook, but libvirt may be more appropriate because qemu could be
> launched with a different security context if loading a virtual disk, rather
> than having qemu set up the security context of the VM.  Thoughts?
>
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/