Are you implying that gaining root access inside a LXC container means that you can escalate to the host system, or to sibling containers?
If yes, I would like to see an example of that (that works on systems with very minimal lockdown, i.e. using the device control group and kernel capabilities).
Otherwise, if you just mean that "0-day Linux root vulnerabilities can be used to escalate from non-root to root in a Linux Containers", that's a truism, and it also stands true for VMs or OpenVZ systems.
Just like 0-day vulnerabilities will help people to escalate from non-root to root in a FreeBSD jail or Solaris zone.
No, I think the implication is that the kinds of kernel bugs that allow you to escalate from a non-root user to root within a container (by corrupting kernel data structures, for instance) will probably also allow you to escalate to root at the host level. If you can change the UID of a process, why should it be harder to change the UID namespace as well?
Plus, the user namespace functionality is fairly new and complex, and there have already been a few bugs found, e.g. [1]. I assume all the known bugs have been fixed, but that doesn't ensure that more aren't lurking somewhere.
Many (though not all) local kernel exploits that allow you to escalate to root will also allow you to run arbitrary code in kernel-space, and there's only one kernel, not one kernel per container.
VMs will always be more secure than containers, simply through defense in depth; the only question is whether you want to trade away some performance and flexibility to increase security.
I disagree with this assertion that "VMs will always be more secure". Of course, they bring an extra layer (or rather, a layer of different nature).
But check the number of Xen vulnerabilities (I kept up with those for a while because I still run a Xen cluster): they are very real. And keep in mind that Xen (at least in my case!) doesn't bring an extra layer of security: if you are (e.g.) an IAAS provider using Xen to sell VMs, your customers can run anything they like in their VMs, and Xen will be the only layer. Your hypervisor will be "on the front line" if you see what I mean.
I would actually argue quite the contrary. I.E.: exploits affecting containers are likely to be exploits affecting all Linux systems, meaning that they will draw much more attention and scrutiny than exploits affecting hypervisors, and they are likely to be fixed faster.
To clarify: VMs will always be more secure for sandboxing a non-root service. In that case, untrusted code would have to get root first, then use that to either replace or exploit the kernel, and then exploit the VM.
In the case where you run untrusted root or kernel code, that code only needs to exploit the VM, true. (On the other hand, many VMs have smaller attack surfaces than the Linux kernel.)
I would disagree with your assertion in the case of PV guests in Xen - they have an extremely small attack surface. The hypervisor may be "on the front line", but is a far simpler beast than the kernel.
Certainly Xen has its fair share of vulnerabilities, but vastly fewer than the kernel.
Comments
Any 0-day Linux root vulnerability qualifies. Linux is a large system, do your own risk analysis.
Are you implying that gaining root access inside a LXC container means that you can escalate to the host system, or to sibling containers?
If yes, I would like to see an example of that (that works on systems with very minimal lockdown, i.e. using the device control group and kernel capabilities).
Otherwise, if you just mean that "0-day Linux root vulnerabilities can be used to escalate from non-root to root in a Linux Containers", that's a truism, and it also stands true for VMs or OpenVZ systems.
Just like 0-day vulnerabilities will help people to escalate from non-root to root in a FreeBSD jail or Solaris zone.
No, I think the implication is that the kinds of kernel bugs that allow you to escalate from a non-root user to root within a container (by corrupting kernel data structures, for instance) will probably also allow you to escalate to root at the host level. If you can change the UID of a process, why should it be harder to change the UID namespace as well?
Plus, the user namespace functionality is fairly new and complex, and there have already been a few bugs found, e.g. [1]. I assume all the known bugs have been fixed, but that doesn't ensure that more aren't lurking somewhere.
[1] http://lwn.net/Articles/543273/
Many (though not all) local kernel exploits that allow you to escalate to root will also allow you to run arbitrary code in kernel-space, and there's only one kernel, not one kernel per container.
VMs will always be more secure than containers, simply through defense in depth; the only question is whether you want to trade away some performance and flexibility to increase security.
I disagree with this assertion that "VMs will always be more secure". Of course, they bring an extra layer (or rather, a layer of different nature).
But check the number of Xen vulnerabilities (I kept up with those for a while because I still run a Xen cluster): they are very real. And keep in mind that Xen (at least in my case!) doesn't bring an extra layer of security: if you are (e.g.) an IAAS provider using Xen to sell VMs, your customers can run anything they like in their VMs, and Xen will be the only layer. Your hypervisor will be "on the front line" if you see what I mean.
I would actually argue quite the contrary. I.E.: exploits affecting containers are likely to be exploits affecting all Linux systems, meaning that they will draw much more attention and scrutiny than exploits affecting hypervisors, and they are likely to be fixed faster.
To clarify: VMs will always be more secure for sandboxing a non-root service. In that case, untrusted code would have to get root first, then use that to either replace or exploit the kernel, and then exploit the VM.
In the case where you run untrusted root or kernel code, that code only needs to exploit the VM, true. (On the other hand, many VMs have smaller attack surfaces than the Linux kernel.)
I would disagree with your assertion in the case of PV guests in Xen - they have an extremely small attack surface. The hypervisor may be "on the front line", but is a far simpler beast than the kernel.
Certainly Xen has its fair share of vulnerabilities, but vastly fewer than the kernel.
I would like to see an example of that...
http://blog.zx2c4.com/749 and http://bit.ly/T9CkqJ
Those are great exploits, but they don't show how to escape from a container at all.
Actually they do. The first in most cases for affected kernels, the latter in many cases.
If you can execute arbitrary code in kernel you can modify anything in any container.
What you say seems intuitively correct to me, but I have to ask (because I am a hardcore pedant)... source?