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

James Morris
2007-07-20T23:33:33Z

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>