Re: A few KVM security questions

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> No.  Paravirtualization just augments the standard hardware interface,
>> it doesn't replace it as in Xen.
> 
> NB, unlike Xen, we can (and do) run qemu as non-root.  Things like
> RHEV-H and oVirt constrain the qemu process with SELinux.
> 

On Xen you can get rid of the qemu entirely, if you run only PV domains.

> Also, you can use qemu to provide the backends to a Xen PV guest (see -M
> xenpv).  The effect is that you are moving that privileged code from the
> kernel (netback/blkback) to userspace (qemu -M xenpv).
> 
> In general, KVM tends to keep code in userspace unless absolutely
> necessary.  That's a fundamental difference from Xen which tends to do
> the opposite.
> 

But the difference is that in case of Xen one can *easily* move the
backends to small unprivileged VMs. In that case it doesn't matter the
code is in kernel mode, it's still only in an unprivileged domain.

Sandboxing a process in a monolithic OS, like Linux, is generally
considered unfeasible, for anything more complex than a hello world
program. The process <-> kernel interface seem to be just too fat. See
e.g. the recent Linux kernel overflows by Spender.

Also, SELinux seems to me like a step into the wrong direction. It not
only adds complexity to the already-too-complex kernel, but requires
complex configuration. See e.g. this paper[1] for a nice example of how
to escape SE-sandboxed qemu on FC8 due to SELinux policy misconfiguration.

When some people tried to add SELinux-like-thing to Xen hypervisor, it
only resulted in an exploitable heap overflow in Xen [2].

[1] http://invisiblethingslab.com/resources/misc08/xenfb-adventures-10.pdf

[2] http://invisiblethingslab.com/resources/bh08/part2-full.pdf

joanna.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]