[ohthehugemanate]

Funny, I never thought about it that way. Namespaced processes being a linux kernel feature in the first place. That's where the whole container thing CAME from in the first place. It's only because the Windows and OSX kernels _don't_ support namespacing, that we have to run docker et al inside a virtual machine on those environments. It is not the container implementation, but the virtual machine, which makes containers "secure" on those platforms.

So put more finely: containers are not secure, anywhere. Virtual machines are. So you should run your containers inside virtual machines if security is important to you. Environments that can't run containers natively are forced into the more secure configuration.

If you're interested in the ongoing work to make containers more secure, Jessie Frazelle has very clear posts on the subject [1][2]. The Bubblewrap project also has a great summary of various approaches being used to "jail" container processes properly. [3]

[1] https://blog.jessfraz.com/post/containers-zones-jails-vms/ [2] https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [3] https://github.com/projectatomic/bubblewrap

[qaq]

"containers are not secure, anywhere" Zones are very secure although you might or might not consider them "containers".

[benmmurphy]

Zones have the same problem that linux containers have which is a massive attack surface in the form of a kernel. And if you think zones are secure: Which OS do you think had more kernel exploits that could be used to escape container/zone in the last 2 years? I think the answer is much closer than you might think.

[qaq]

I am not tracking closely to be honest since I have not being working with Illumos based distros for 5 years +/- when we were using omniOS I do not remember things being too bad. Not sure what % of vuln. are Oracle Solaris specific given that majority of orig. SUN eng. left long time ago Illumos might be in much better shape vs Solaris.

[helper]

http://www.zerodayinitiative.com/advisories/ZDI-16-168/

http://www.zerodayinitiative.com/advisories/ZDI-16-274/

These were both in Illumos found by the person you are replying to.

[qaq]

Good point does not look too horrible as far as track record though :) less than number of docker vuln. and about the same as vmware which is an actual vm

[helper]

Please don't take the first two urls I found with a single google search as a comprehensive survey of Illumos kernel vulnerabilities over the last few years.

[thinkpad20]

> containers are not secure, anywhere. Virtual machines are.

Can you (or someone else) ELI5 what makes containers insecure? Not a low level Linux or security expert.

[tyingq]

I'm sure there's more, but the most obvious is that they share one running kernel. So, one kernel exploit in one container means you now have all the running containers.

[thinkpad20]

So containers are as vulnerable as the operating system? It seems like if your kernel has been pwned you’re already SOL? Or couldn’t someone in that position just as easily pwn a VM, or run the same exploit on multiple vms? I’m not sure if I’m missing something

[cestith]

Let's say you break out of a web app on a VM, then as the local user you exploit the kernel. It's the VM host kernel. You have root on the VM. The VM is running on a full virtualization platform, though, so you'd need to break out of the VM to hit other guests or the hypervisor.

Linux containers run a new environment on top of the host's kernel. It's the same kernel in one container as another and the same as in the host. If you manage to break out of the namespace or otherwise exploit the kernel, you're already in some other container's business. Worse, there's a good chance you've exploited the kernel in a way that you can get all the other containers and the host all at once with one exploit.

[tyingq]

Assuming the attacker already knew the IP of every VM, and they were all running the same kernel with the same exploit, and they were all exposed to the internet, it would be similar...although you would have to repeat the steps 'N' times. Or, assuming you could somehow escalate your VM kernel exploit to a higher level hypervisor exploit and get to the top.

That's not usually the case, though.

With containers, you get the kernel exploit, and you're in, for the most part.