[libvirt] Re: [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization

[Daniel P. Berrange]

On Tue, Aug 12, 2008 at 03:57:46PM +1000, Russell Coker wrote:
> On Monday 11 August 2008 19:31, James Morris <jmorris at namei.org> wrote:
> I think that Casey's idea is that if someone breaks the VM separation then you 
> lose it all.  For separation based on UML there are obvious benefits to 
> having different labels for processes and files so that if someone cracks the 
> UML kernel then they end up with just a regular user access on the Linux 
> host.  Which of course they could then try to crack with any of the usual 
> local-root exploits.
> 
> For separation based on Xen if someone cracks the hypervisor then you lose 
> everything.

Xen is out of scope for this initial work, because we don't want to get
involved in the hypervisor code, since then we have to deal with the
Xen XSM framework too.

> For KVM (which seems to be the future of Linux virtualisation) I don't know 
> enough to comment.

In KVM, virtual machines really are just processes as far as the host
OS is concerned. It is very similar to UML in this respect, except you
don't need to have a special kernel image for your VM.

> > Again, keep in mind that we're talking about Linux-based virtualization,
> > where the VM is literally just another application running in the host OS.
> 
> So by "Linux-based" you mean in contrast to Xen which has the Xen kernel (not 
> Linux) running on the hardware?

By Linux-based we mean a virtualization platform where Linux *is* the
hypervisor. This includes KVM, UML. It specifically excludes Xen, since
it has a separate hypervisor underneath the host kernel. That's not to
say the work couldn't be extended to Xen later, its merely not a core
focus.

> The issue is whether the hypervisor you care about can be broken out of in 
> that way.  It seems that if someone can break out of Xen then you just lose.  
> For KVM I don't know the situation, do you have a good reference for how it 
> works?
> 
> http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
> 
> The above web page says that KVM is all based in the kernel, in which case why 
> would it be any more resilient than Xen?

The best way is to thing of KVM, as an accelerator for QEMU. If you're
not already familiar, QEMU provides CPU emulation, and device emulation
for a wide variety of platforms. The KVM kernel module basically provides
a simple API to userspace which allows QEMU's CPU emulation to be switched
out in favour of using hardware virtualization capabilities available from
latest generation CPUs. The QEMU device emulation is still used.

People typically claim that Xen is more resilient than KVM because it has
a separate hypervisor and thus has a smaller trusted codebase. In practice
this is smoke & mirrors, because to do anything useful Xen still has this
Dom0 host kernel which has access to all hardware. So I wouldn't claim 
either Xen or KVM are inherantly more secure than each other. 

> > > >       o Consolidating access to multiple networks which require strong
> > > >         isolation from each other (e.g. military, government, corporate
> > > >         extranets, internal "Chinese wall" separation etc.)
> > >
> > > The VMs provide this. Isolation is easy. Sharing is what's hard.
> >
> > Again, it's important to understand that these VMs are merely Linux
> > processes and are only currently afforded the same level of isolation as
> > standard DAC.
> 
> How does the "VMs are merely Linux processes" fit with the description of KVM?  
> Or are you talking about some other virtualisation system?

Again think of the KVM kernel module as simply a CPU accelerator for QEMU. 
A VM is just a QEMU process which is using KVM for its CPU virtualization.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|