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

[James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>]

On Fri, 20 Jul 2007, Anthony Liguori wrote:

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

Right, we are talking about specific invocations of qemu running in 
different security domains.  SELinux policy at the OS level would control 
what each domain (i.e. instance of qemu) can do.

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

We need some mechanism to invoke VM instances so that they execute in a 
specific security domain, and to ensure that the domain performing the 
invocation is authorized to do so, on the specific disk image, and to be 
transitioned to a specific domain of execution according to policy.

This is just the invocation phase.

There may need to be further controls on e.g. inter-VM communication or 
other things which may operate outside the standard host OS mechanisms.

I'm not sure exactly what syscall passthrough entails, or what the 
security implications are.  How would it make it impossible to have a 
security-aware launcher (i.e. the application which invokes the VM 
instance per above) ?



- James
-- 
James Morris
<jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>

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