It's kind of interesting that it's only in the Linux world that containers cannot be thought of as isolated or secure. Seeing it from a jails and zones perspective, rather sad, actually :)
FreeBSD jails are known to not be silver bullets. I've heard many instances of breaking out of a FreeBSD jail.
Generally, treating any OS-level technology as a silver bullet is a huge mistake. Any serious developer would make multiple levels of security that _should_ be sound.
That's quite true. Any serious FreeBSD will readily acknowledge such(eg https://www.freebsd.org/doc/handbook/jails.html), but the project does try to default to sensible security defaults for it's containers eg no raw sockets.
While not applicable to FreeBSD alone, this polemic thread:
is a pretty accurate description of container level security and not much has changed. Stuff built on a foundation is always subject to the foundation's qualities.
This is the most blatant and clearly incorrect... FUD?..lie?... I have ever heard to date about jails.
Jails are secure. As are SmartOS zones. Whoever you heard that there are “many instances of breaking out of a jail” from is full of sh47. And you would be wise to never listen to them ever again. No really, EVER.
And no, breaking the ps4 was not a jail exploit. The attacker already had elevated privileges. So you would be sunk no matter what.
Sheesh, no need to get so emotional about it. I said instances of breaking out, not instances of jail exploits. I don't know of any jail-specific exploits.
But when we say "elevated privileges" are we talking root inside of a jail? Because if that breaks jails, then a large class of Docker exploits also wouldn't classify as 'exploits' under that criteria. One of the biggest problems with Linux namespaces is the band-aid put over root, via capabilities.
As far as I know, though, the PS4 exploit was more Sony's fault. IIRC, they broke out of the jail by exploiting custom syscalls not in stock FreeBSD. Bugs in syscalls in FreeBSD aren't unheard of though, even if less commonly found than Linux.
My entire point is that good security implies not treating any solution as a panacea, lest you find yourself in a digital Titanic scenario. Multiple layers of solid security beats one layer of solid security.
i believe there was an exploit by another team which used badiret. which is pretty hilarious because badiret has been patched ages ago but FreeBSD never told anyone they fixed it.
yeah there are probably not many 'jail' exploits specifically targeted for getting out of jail/exploiting jail primitives. but people just use normal kernel exploits to get out of jail/zones. i would say jails/zones are about as secure as linux containers. ie: about as secure as the linux kernel is.
He gave a talk at DTrace conf 2016 about all the security vulnerabilities he personally found in DTrace in SmartOS. Here are the slides: http://slides.com/benmurphy/deck
> Kata Containers combines technology from Intel® Clear Containers and Hyper runV
but I can't find a mention of Hyper-V anywhere (which doesn't mean there was no inspiration). Maybe you confused Hyper runv and Hyper-V here (the naming certainly doesn't help)?
I might have just been confused due to the naming, but, as far as I can see, they’re using the exact same underlying technology, based on AMD’s and Intel’s virtualization extensions, to replace the sandboxing that is currently handled by kernel namespaces, jails, or HyperV containers (and, in some of these implementations, already uses this technology)
runV is a oci compatible drop in replacement for runC that can execute containers on a number of backend virtualisation environments, including Hyper-V and KVM
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]
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.
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.
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
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.
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
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.
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.
Generally, treating any OS-level technology as a silver bullet is a huge mistake. Any serious developer would make multiple levels of security that _should_ be sound.