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 <[EMAIL PROTECTED]> ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
