[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kvm
Subject:    Re: A few KVM security questions
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2009-12-07 17:58:11
Message-ID: 4B1D4233.1070105 () invisiblethingslab ! com
[Download RAW message or body]

Anthony Liguori wrote:
> 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.
> 

I think this ultimately comes down to the question: is the
built-from-scratch minimal PV interface (as in Xen) more secure than the
Linux's fat-but-sandboxed interface?

joanna.


["signature.asc" (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]