The first stable OpenVZ release [LWN.net]

The first stable OpenVZ release

Posted Dec 9, 2005 14:17 UTC (Fri) by PaXTeam (subscriber, #24616)
In reply to: The first stable OpenVZ release by riel
Parent article: The first stable OpenVZ release

> For the truly paranoid, a virtualization model where each virtual machine has its own kernel (ie. Xen) probably makes more sense.

actually, exactly the opposite is true. think about it, a set of virtual machines is the equivalent of a set of (optionally networked) physical machines. the difference is that when you compromise a machine (virtual or physical, respectively) and want to escalate your access (within the given machine or across machines), under the virtual system you get an extra potential attack vector - the VM supervisor/hypervisor/whatever itself. so the VM model is *always* less secure than the equivalent set of physical machines. and that's why kernel security (and in particular, its resistance to exploits) is even more important than on 'normal' machines.

(Log in to post comments)

The first stable OpenVZ release

Posted Dec 15, 2005 23:08 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]

you misunderstood my comment. it wasn't about Xen vs. OpenVZ but about <any VM solution> vs. physical machines. and the reason for that was the 'truly paranoid' part of his comment, as that (to me at least) implies the 'maximum (kernel) security', which cannot be <any VM solution> by definition, so the 'truly paranoid' is not better off by Xen.

as for whether Xen or OpenVZ has better 'kernel' security, it depends on what privilege escalation you're interested in.

for cross-VM escalation ('getting root in another VM from your current VM'), Xen could be better off since there you'd have to exploit a hypervisor bug (in addition to a per-VM kernel bug) whereas in OpenVZ exploiting a kernel bug is an automatic cross-VM exploit as well (well, modulo their security measures that we have yet to hear from the developers). whether Xen's hypervisor is exploitable or not is an open question.

for in-VM escalation ('getting root in the current VM from a non-privileged account'), there's no difference between the two, exploiting a kernel bug will achieve it in both cases (modulo again the OpenVZ security measures, which can of course be applied under Xen as well, so they'd still be equal).

The first stable OpenVZ release

Posted Dec 15, 2005 23:17 UTC (Thu) by riel (subscriber, #3142) [Link]

Note that with Xen you could implement some security measures that can not be as easily exploited on a physical computer or with a single-kernel model.

It is possible for the hypervisor to enforce that certain memory in the virtual machine is read-only, and only that memory can be mapped at certain virtual addresses. Using this protection, you can restrict the memory that kernel exploits can mess with, protecting things like kernel text, the system call table, kernel page tables, etc...

This security can not be easily circumvented if there is a kernel bug, since it is enforced by the hypervisor.

The first stable OpenVZ release

Posted Dec 16, 2005 15:41 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]

part of what you described as a potential feature in Xen has been implemented in PaX for something like 2.5 years now (KERNEXEC is the feature name). the reamining parts can be implemented as well, but that's quite some work i haven't found the time for yet. so single kernel image solutions can be made as resistant as what you said about Xen. this is actually the reason i asked about OpenVZ's hardening features, as i've been working on similar techniques and am obviously interested in other ideas.