6 ms·

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 perspect

by chungy 9y ago

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 :)

oblio 9y ago
Does Windows have anything like this?
- kuschku 9y ago
  Yes – HyperV containers (which Kata is actually inspired by) are much more secure than Linux’ namespaces.
  - tilpner 9y ago
    > 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)?
    - cbzbc 9y ago
      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
      - jchw 9y ago
        That's coincidence, though. runV wasn't inspired by Hyper-V.
    - kuschku 9y ago
      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)
ohthehugemanate 9y ago
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/ https://blog.jessfraz.com/post/containers-zones-jails-vms/ [2] https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [3] https://github.com/projectatomic/bubblewrap https://github.com/projectatomic/bubblewrap
- thinkpad20 9y ago
  > 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 9y ago
    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 9y ago
      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
jchw 9y ago
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.
- X86BSD 9y ago
  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.
  - jchw 9y ago
    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.
    - benmmurphy 9y ago
      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.

by chungy 9y ago

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 :)

oblio 9y ago

Does Windows have anything like this?

kuschku 9y ago
Yes – HyperV containers (which Kata is actually inspired by) are much more secure than Linux’ namespaces.
- tilpner 9y ago
  > 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)?
  - cbzbc 9y ago
    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
    - jchw 9y ago
      That's coincidence, though. runV wasn't inspired by Hyper-V.
  - kuschku 9y ago
    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)

ohthehugemanate 9y ago

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/ https://blog.jessfraz.com/post/containers-zones-jails-vms/ [2] https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [3] https://github.com/projectatomic/bubblewrap https://github.com/projectatomic/bubblewrap

thinkpad20 9y ago
> 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 9y ago
  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 9y ago
    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

jchw 9y ago

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.

X86BSD 9y ago
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.
- jchw 9y ago
  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.
  - benmmurphy 9y ago
    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.