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

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

James Morris wrote:
> On Fri, 20 Jul 2007, 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.
>>     
>
> Yep, I was thinking only about qemu.
>
> I guess you'd have OS policy preventing normal domains from accessing 
> /dev/kvm (or /dev/lguest etc.), while a security-aware launcher would 
> enforce access control policy over which domains could launch which disk 
> images as VMs, and also setup the execution context & fork.
>   

I really think you have to start with the assumption that a guest can 
access anything that QEMU can access and attempt to build security 
around that.  If you want to restrict what the guest can see, restrict 
what QEMU can see.

At some point, we may do crazy stuff like syscall pass-through in which 
case, it would be all but impossible to have a "security-aware" launcher.

Regards,

Anthony Liguori

> So, perhaps this would be better done at the libvirt layer (i.e. make 
> libvirt the object manager).
>
>
>
> - James
>   


-------------------------------------------------------------------------
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/