| |||||||||||||
The first stable OpenVZ releaseThe first stable OpenVZ releasePosted Dec 15, 2005 17:44 UTC (Thu) by boklm (subscriber, #34568)In reply to: The first stable OpenVZ release by PaXTeam Parent article: The first stable OpenVZ release
I think he was talking about Xen vs OpenVZ virtualization techniques security, not VM vs physical machines security.
(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.
|
|||||||||||||