Re: A few KVM security questions

[Anthony Liguori <anthony@codemonkey.ws>]

Joanna Rutkowska wrote:
> 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.
>   

Right, in KVM, Linux == hypervisor.  A process is our "unprivileged 
domain".  Putting an unprivileged domain within an unprivileged domain 
is probably not helpful from a security perspective since the exposure 
surface is identical.

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

That's the point of mandatory access control.  Of course, you need the 
right policy and Spender highlighted an issue with the standard RHEL 
SELinux policy, but that should be addressed now upstream.

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

It's certainly fair to argue the merits of SELinux as a mandatory access 
control mechanism.

Again though, that's the point of MLS.  Our first line of defense is 
qemu.  Our second line of defense is traditional Posix direct access 
control.  Our third line of defense is namespace isolation (ala lxc).  
Our fourth line of defense is mandatory access control (ala SELinux and 
AppArmor).

If you take a somewhat standard deployment like RHEV-H, an awful lot of 
things have to go wrong before you can successfully exploit the system.  
And 5.4 doesn't even implement all of what's possible.  If you're really 
looking to harden, you can be much more aggressive about privileges and 
namespace isolation.

Regards,

Anthony Liguori