| |||||||||||||
The first stable OpenVZ releaseThe first stable OpenVZ releasePosted Dec 6, 2005 7:28 UTC (Tue) by job (guest, #670)In reply to: The first stable OpenVZ release by kolyshkin Parent article: The first stable OpenVZ release
I would like to know more about how OpenVZ adds security compared to a conventional chroot/chuid solution. It was my understanding that you can't bypass that without a kernel exploit, and that's probably something OpenVZ can't defend against?
(Log in to post comments)
The first stable OpenVZ release Posted Dec 6, 2005 9:46 UTC (Tue) by dev (guest, #34359) [Link] chroot/chuid is not a secure solution in many respects:- you can easily make a DoS on memory/CPU/disk and other resources, which are out of control of ulimits. In OpenVZ you control how many CPU/memory and disk space your VPS can consume. - root can break chroot. So you can't give people root access under chroot. This also implies that you can't run many software which require root priviliges, can't listen on some port numbers etc. - root can break chroot. This also implies, that if a hacker has accessed your system being under chroot() and is able to gain root privileges (which is not a hard problem due to SUID apps and security problems in modern software) he will be able to get out of chroot.
2 last points are not applicable to OpenVZ: you have root privileges in VPS, you can run any application you wish and it is imposible to get out of VPS due to enhanced security model and lots of preventive countermeasures which are created just to be sure that no harm can be done.
The first stable OpenVZ release Posted Dec 6, 2005 15:53 UTC (Tue) by PaXTeam (subscriber, #24616) [Link] > it is imposible to get out of VPS due to enhanced security model and lots> of preventive countermeasures which are created just to be sure that no > harm can be done
how do you prevent exploiting kernel bugs (which is what the OP was asking about i think)?
The first stable OpenVZ release Posted Dec 6, 2005 19:58 UTC (Tue) by dev (guest, #34359) [Link] There are probably 2 kinds of kernel bugs:- oopses/bugs which are not exploitable, but probably triggerable. These are just fixed in a timely manner (even faster than in RHEL, you can check update history). - exploitable bugs which allow to gain root privileges. These bugs allow to gain root privileges, but you are still bounded to VPS just in any VM-like solution. - exploitable bugs which allow to write kernel memory. These bugs allow crash the whole system or theoretically to get out of VPS. For this kind of bugs we have some countermeasures (e.g. in VFS).
So the most dangerous category of bugs is the 3rd one, but happily almost all kernel bugs belong to 1st category.
So the answer for your question is: we fix known bugs in a timely manner and insert countermeasures against getting out of VPS boundaries.
The first stable OpenVZ release Posted Dec 6, 2005 20:29 UTC (Tue) by PaXTeam (subscriber, #24616) [Link] it's the 3rd kind of bugs which i am interested in, and in particular your specific countermeasures. is there some documentation on it (or at least some pointers as to what i should be looking for in your kernel patch)?
The first stable OpenVZ release Posted Dec 9, 2005 4:45 UTC (Fri) by riel (subscriber, #3142) [Link] For the truly paranoid, a virtualization model where each virtual machine has its own kernel (ie. Xen) probably makes more sense. On large servers with only a handful of virtual machines, this model works great too.
However, for massive virtualization (think of ISPs, with hundreds of virtual machines on a system) the lower memory overhead and more flexible resource allocation of OpenVZ are probably very much worth it.
Both virtualization models have their place. I hope that we'll end up seeing both in the upstream kernel.
The first stable OpenVZ release Posted Dec 9, 2005 14:17 UTC (Fri) by PaXTeam (subscriber, #24616) [Link] > 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.
The first stable OpenVZ release Posted Dec 15, 2005 17:44 UTC (Thu) by boklm (subscriber, #34568) [Link] I think he was talking about Xen vs OpenVZ virtualization techniques security, not VM vs physical machines security.
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.
The first stable OpenVZ release Posted Dec 9, 2005 14:22 UTC (Fri) by madscientist (subscriber, #16861) [Link] I agree that _IF_ the OpenVZ model allows for much more efficient utilization of resources that it would be a valuable addition to the kernel, and worth having both types of virtualization available.
Just a point, though: "true paranoia" is not the only reason to choose a UML/Xen model. At work, for example, we develop embedded software, and we use UML as a simulation environment. We can run three, four, or even more "virtual machines" on our desktops using UML, and hook them together with networking. Obviously we don't want to be forced to run the same kernel on our desktops that we use in our embedded system.
As another example, at home I'm forced to use a proprietary VPN solution to work from home (that's the only method they support for remote access). This solution has a binary-only kernel module and as with all such modules, they only support a limited set of kernel versions. I can use UML to run a virtual machine with the correct kernel version to connect to work, while still using the kernel I prefer natively.
The first stable OpenVZ release Posted Dec 18, 2005 10:14 UTC (Sun) by dev (guest, #34359) [Link] Sorry for delay.Sure, we can't prevent exploiting kernel bugs at all. All we can do is to add some barriers which would require special knowledge and efforts to overcome them. Some of them are: d_root_check(), check_area_XXX() which try to prevent access to files 100% not belonging to the user. another idea which you brought to me with your message - is to extend vps_dumble flag (which is another security extension, preventing host process to be dumpable when it "entered" the VPS), so that process from host system would always stay undumpable for VPS, not on "enter" only. If you have some other ideas on security, I will be glad to discuss it and hear you opinion on this topic. Probably it's better if we move to devel at openvz dottt org what do you think?
|
|||||||||||||