On 7/21/07 2:21 AM, "Avi Kivity" <[EMAIL PROTECTED]> 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.  

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/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to