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.
Attachment:
signature.asc
Description: OpenPGP digital signature
