6 ms·

Nice article! Though I do think the article could have more clearly noted that Linux containers are not meant as security boundaries. It doesn't explicitly say

Nice article! Though I do think the article could have more clearly noted that Linux containers are not meant as security boundaries. It doesn't explicitly say it but it is a very important distinction. Unlike FreeBSD jails and Solaris Zones. You can't run multiple docker tennant's safely on the same hardware. Docker is basically the equivalent of a sign which says: "don't walk on the grass" as opposed to an actual wall which FreeBSD jails and Solaris zones have. Now if you have a very homogene environment (say you are deploying hundreds of instances of the exact same app) then this is probably fine. Docker is primarily a deployment tool. If your an organization which runs all kinds of applications (with varying levels of security quality) that's an entirely different story.

okket 9y ago
Maybe relevant: "Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs" https://blog.jessfraz.com/post/containers-zones-jails-vms/ https://blog.jessfraz.com/post/containers-zones-jails-vms/ Some discussion about this article here on HN: https://news.ycombinator.com/item?id=13982620 https://news.ycombinator.com/item?id=13982620 (160 days ago, 235 comments)
- jsiepkes 9y ago
  True, and that very long post basically says with many words: "Yes, Linux namespace (docker) isn't as secure as FreeBSD jails or Solaris Zones but security is not the problem docker solves. Docker solves a deployment problem, not a security problem."
  - gvb 9y ago
    Comparing containers (a concept) with VM/jails/zones is a non-sequitur. To quote: A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. [...] VMs, Jails, and Zones are if you bought the legos already put together AND glued. So it’s basically the Death Star and you don’t have to do any work you get it pre-assembled out of the box. You can’t even take it apart. Containers come with just the pieces so while the box says to build the Death Star, you are not tied to that. You can build two boats connected by a flipping ocean and no one is going to stop you. Docker is a bunch of boxes floating on a flipping ocean[1]. They could have made a deathstar, but they chose not to. [1] https://www.google.com/search?q=docker+logo https://www.google.com/search?q=docker+logo
  - KGIII 9y ago
    Can't you just run docker in something like firejail?
TheDong 9y ago
Given that's the case, I'm sure you can go capture the flag at https://contained.af/ https://contained.af/ .. no one has yet (docker containers, heavy seccomp filtering). Or maybe you can break out of the Google App Engine linux container and let me know how it looks (linux containers, quite well-worn at this point)? Or perhaps you can check for me whether AWS Lambda actually collocates tenents or not (unknown linux containers)? Or you can launch a heroku dyno and break into another dyno and steal some keys (lxc linux containers)? In reality, many services do colocate multiple different users together in linux containers. If you use seccomp and ensure the user is unprivileged in the container, it's fairly safe. Heroku has been doing it for years upon years now. The other services I named above likely do. Linux containers absolutely are intended as security boundaries. Kernel bugs which allow escaping a properly setup mount namespace or peeking out of a pid namespace or going from root in a userns to root on the host are all treated as vulnerabilities and patched. That clearly expresses the intent. Yes, I agree that in reality they're likely not yet as mature / secure as jails or zones, but I think it's disingenuous to say that Linux containers aren't meant to be security boundaries.
- ungamed 9y ago
  > . Kernel bugs which allow escaping a properly setup mount namespace or peeking out of a pid namespace or going from root in a userns to root on the host are all treated as vulnerabilities and patched. That clearly expresses the intent. This is because these vulns can be exploited locally without containers.
zlynx 9y ago
There are dangerous things that you can allow Docker to do. But if you don't do those things, it is pretty difficult to break out of a container. Redhat has been especially good here, with not allowing anyone but host-root to connect to Docker and using SELinux and seccomp filtering. With those working, it doesn't matter if your container mounts a host filesystem since it won't have the correct SELinux roles and types anyway. Many people claim that ruins Docker, since now you can't use Docker from within Docker. But that's the price you pay for security. I believe that with the correct precautions, a Linux container is just as safe as a jail or zone. Perhaps the problem is just how easy it is for a sysadmin to put holes into the containers that ruin the security.
- s_kilk 9y ago
  > since now you can't use Docker from within Docker. Docker-in-docker is a trashfire that barely works anyway, it's no real loss.
  - bboreham 9y ago
    Think you might be talking about running the Docker daemon inside Docker, which is a different thing from just calling Docker from a container.
    - s_kilk 9y ago
      Ah, you're right. The latter is actually a pretty cool solution, I've had great success with using it to spawn what are essentially sibling containers.
- mirashii 9y ago
  > Perhaps the problem is just how easy it is for a sysadmin to put holes into the containers that ruin the security. I think there's a bit more to it than that. For some examples of other reasons people might be wary vs zones: docker itself is still a daemon that runs as root, combining a large number of different functionalities which require root access into a single binary with a large attack vector and a lot of code which doesn't need to be privileged. While isolation of responsibilities of docker has begun, even their own security page [1] admits that there's a long way to go here. Zones are, as many of the articles in this thread point out, a first class feature designed and implemented. What docker/"containers" allow you to do is the culmination of many building blocks which have been incrementally added to the Linux kernel. Some of those have been pretty recently, and without an overall design, their interactions with other portions of the Linux kernel or other components of the system have often been surprising and led to a number of security issues over time. In comparison, both the code and the design of the system are relatively young. A good example of this can be found at [2], which ends with the following very apt quote: > Why is it that several security vulnerabilities have sprung from the user namespaces implementation? The fundamental problem seems to be that user namespaces and their interactions with other parts of the kernel are rather complex—probably too complex for the few kernel developers with a close interest to consider all of the possible security implications. In addition, by making new functionality available to unprivileged users, user namespaces expand the attack surface of the kernel. Thus, it seems that as user namespaces come to be more widely deployed, other security bugs such as these are likely to be found. It might also be interesting to read [3], which is already showing that 3.5 years later, user namespaces are still a breeding ground for security issues that lead to privilege escalation. [1] https://docs.docker.com/engine/security/security/#related-information https://docs.docker.com/engine/security/security/#related-in... [2] https://lwn.net/Articles/543273/ https://lwn.net/Articles/543273/ [3] https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespacesWhySecurityProblems https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespace...
rodgerd 9y ago
The fact this is the top-rated comment really does say a lot about the technical literacy of the newsy audience.
- unethical_ban 9y ago
  Multiple explanations, not all of which need to be the case: * Not everyone needs or is an expert on containers, just as not everyone is knowledgable about the TCP stack, dynamic routing, assembly optimization, or name your topic. * It's a true and well-stated comment in itself and deserves to be recognized, even if many already know it.
rjzzleep 9y ago
It's just sad to watch this. the fact that the whole root zone etc. is just built right into every part of the os is amazing. And yet you have a bunch of companies just stroking their egos. I looked at the illumos-gate and smartos contributors as brendan suggested and there isn't much. I wonder if adding a proper wifi stack and commodity hardware supported would have helped. Maybe it's just wishful thinking but I thought it would have been nice for cheap routers and home nas. The fact that there is so little documentation also probably didn't help it
ryanlol 9y ago
... Precisely none of these are technologies that you should use to "safely" run multiple things on the same hardware.
DCKing 9y ago
I'm not sure what you mean here. Do you mean that: 1) There are known ways to perform Docker escapes on any or some common Docker setup. You could write a Docker escape binary or script today and it would not be a zero day. That's just the way Docker is. -or- 2) You simply have less faith in the ways Docker performs isolation. One could write a Docker escape exploit and it would be a zero day, but you expect there to be more of such zero days in Docker than in Jails/Zones. ? If 1) I'd be really interested in seeing it and if 2) I'd like to know more about what additional levels of isolation jails and zones (and LXC?) perform.
- mirashii 9y ago
  I've expanded a little bit more in another comment here, but I think 2) is less a case of any fundamentally different level of isolation, but more a maturity of design and implementation. While Zones were designed as first class, containers were not, they're built out of a variety of other building blocks, which while they may be more powerful primitives, have seen less review of design and implementation and exposed a large attack space on the kernel. User namespaces are the prime example, possibly because they are the largest/juiciest new target, but I expect we'll see more with time.
Spooky23 9y ago
Linux containers are very similar to Zones. I doubt you would choose between the two technologies based on security.
raesene9 9y ago
I'd be very interested to hear details of exactly how you would suggest, if I understand you correctly, that any Linux container can be broken out of. With user namespacing in use (available in Docker since 1.12) I'm not currently aware of any trivial container-->host breakouts or container --> container breakouts. There are information leaks from /proc but they don't generally allow for breakout, and in general Dockers defaults aren't too bad from a security standpoint. The only exception for the general case is, I'd say, the decision to allow CAP_NET_RAW by default, which is a bit risky.
- Hello71 9y ago
  https://google.com/search?q=user+namespace+vulnerability https://google.com/search?q=user+namespace+vulnerability https://lwn.net/Articles/543273/ https://lwn.net/Articles/543273/ https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespacesWhySecurityProblems https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespace...
  - raesene9 9y ago
    Right so each of those are specific vulns. like all code gets, and not a systemic "linux containers aren't a security boundry" as suggested by the OP, which was the point I was asking for more info. on. All code has bugs, some of those are security bugs. There's a big difference between "if you haven't patched or I have a 0-day I can compromise you" and "no matter how well patched you are this isn't a security boundry so it can be bypassed" My reading of the top comment was it was suggesting the latter with regard to Linux containers, and I'm not sure that's true.
    - openasocket 9y ago
      Yes, but certain things tend to wind up with more security bugs than others, due to attack surface and the like. For instance, you tend to see browser exploits, SSL exploits, and privilege escalation attacks a lot more often than OS-level exploits, or hypervisor vulnerabilities. It's not that Docker is a gaping security hole, it's just not something I trust as much as the Linux Kernel or Xen. I probably trust it about as much as I trust a well-updated web browser. It's suitable for everyday use, but I don't click the link on the phishing or spam email just to see what happens.
vishvananda 9y ago
> Docker is basically the equivalent of a sign which says: "don't walk on the grass" as opposed to an actual wall which FreeBSD jails and Solaris zones have. I think this is dramatically overstating the risks. It is possible to run containers securely, it is just much more difficult to secure containers on linux than on BSD or Solaris. It is significantly difficult to break out of a properly configured container (using user namespaces, seccomp, and selinux/apparmor), and I know of no cases where it has been done successfully. I still separate tenants onto VMs because I don't want to be the first example of a breakout, but I don't think people who isolate with containers are crazy, just a little less risk-averse.
- solatic 9y ago
  > I think this is dramatically overstating the risks. It is possible to run containers securely, it is just much more difficult to secure containers on linux than on BSD or Solaris. The more difficult it is for sysadmins to harden their Docker setup, the less credence can be given to the claim that Docker is designed for security isolation. In the real world, security compromises happen far more often because of misconfigured setups, not because of zero-day exploits. This is why it's important for software in general to be shipped with secure defaults. I can't remember the source, so I'll paraphrase, but a rather wise guy once said: "I don't care how hard it is to break a hardened setup - what I'm concerned about is how easy it is to harden." Out of the box, Docker is designed to solve deployment problems, not security problems. And that's a crucial distinction.
e12e 9y ago
> Linux containers are not meant as security boundaries (...) > You can't run multiple docker tennant's safely on the same hardware. Docker is basically the equivalent of a sign which says: "don't walk on the grass" as opposed to an actual wall (...) I agree, but it's a strange way to frame it - the technology is lxc - and lxc (along with some enabling technologies and tools) do have, and has a history of, a focus on being a real boundary. docker has never (does now?) claimed, or implemented - or been about security boundaries. Stretching the metaphor, docker is using tar to package dependencies in a snapshot, and using plain chroot to run "containers" - even when jails are available. In terms of marketing, "Linux containers" might mean "docker" - but in technology (as contrasted with zones, jails) that's not quite right. So yes, "docker is not about security", lxc&friends maybe not quite equivalent to modern jails - but new ways of running "docker containers", like in actual vms - certainly can blend some convenience/popularity and security.
- IgorPartola 9y ago
  I am confused. I thought Docker was no longer based on LXC. Am I wrong on this?
  - e12e 9y ago
    The whole story is somewhat long and complicated - I think it was roughly openvz (patch-set, out-of-tree for Linux "jails" > lxc > [docker enters the picture] > as more features for isolation are merged in mainline (namespaces ++) it means docker is no longer based on the same subset of features that the lxc project uses. I'm sure someone will chime in with an updated family tree of Linux chroots, capability frameworks and process isolation features. [ed: i believe one source of confusion is that docker started with (userspace part of) lxc as its only driver, and now docker-the-binary makes system calls directly, and avoids lxc-the-userspace-toolset - but they employ a mish-mash of kernel features, many-of came from the lxc project (on the kernel side)?]
emmelaich 9y ago
Openshift give you a free container with no more id than an email address. So clearly it can be made secure. Though I admit this would not be core docker stuff; more like selinux and other controls.
hacknat 9y ago
Linux does offer enough primitives to completely sandbox processes, as Zones and Jails did/do. The problem is that docker didn't implement all of those primitives right away, the biggest being user namespacing, which it didn't add until shockingly late in its development lifecycle. So, yes you can completely sandbox a "container", just be prepared to put in some work (SELinux, AppArmor, user namespaces, and reviewing the defaults capabilities quite carefully).

okket 9y ago

Maybe relevant: "Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs" https://blog.jessfraz.com/post/containers-zones-jails-vms/ https://blog.jessfraz.com/post/containers-zones-jails-vms/ Some discussion about this article here on HN: https://news.ycombinator.com/item?id=13982620 https://news.ycombinator.com/item?id=13982620 (160 days ago, 235 comments)

jsiepkes 9y ago
True, and that very long post basically says with many words: "Yes, Linux namespace (docker) isn't as secure as FreeBSD jails or Solaris Zones but security is not the problem docker solves. Docker solves a deployment problem, not a security problem."
- gvb 9y ago
  Comparing containers (a concept) with VM/jails/zones is a non-sequitur. To quote: A “container” is just a term people use to describe a combination of Linux namespaces and cgroups. Linux namespaces and cgroups ARE first class objects. NOT containers. [...] VMs, Jails, and Zones are if you bought the legos already put together AND glued. So it’s basically the Death Star and you don’t have to do any work you get it pre-assembled out of the box. You can’t even take it apart. Containers come with just the pieces so while the box says to build the Death Star, you are not tied to that. You can build two boats connected by a flipping ocean and no one is going to stop you. Docker is a bunch of boxes floating on a flipping ocean[1]. They could have made a deathstar, but they chose not to. [1] https://www.google.com/search?q=docker+logo https://www.google.com/search?q=docker+logo
- KGIII 9y ago
  Can't you just run docker in something like firejail?

TheDong 9y ago

Given that's the case, I'm sure you can go capture the flag at https://contained.af/ https://contained.af/ .. no one has yet (docker containers, heavy seccomp filtering). Or maybe you can break out of the Google App Engine linux container and let me know how it looks (linux containers, quite well-worn at this point)? Or perhaps you can check for me whether AWS Lambda actually collocates tenents or not (unknown linux containers)? Or you can launch a heroku dyno and break into another dyno and steal some keys (lxc linux containers)? In reality, many services do colocate multiple different users together in linux containers. If you use seccomp and ensure the user is unprivileged in the container, it's fairly safe. Heroku has been doing it for years upon years now. The other services I named above likely do. Linux containers absolutely are intended as security boundaries. Kernel bugs which allow escaping a properly setup mount namespace or peeking out of a pid namespace or going from root in a userns to root on the host are all treated as vulnerabilities and patched. That clearly expresses the intent. Yes, I agree that in reality they're likely not yet as mature / secure as jails or zones, but I think it's disingenuous to say that Linux containers aren't meant to be security boundaries.

ungamed 9y ago
> . Kernel bugs which allow escaping a properly setup mount namespace or peeking out of a pid namespace or going from root in a userns to root on the host are all treated as vulnerabilities and patched. That clearly expresses the intent. This is because these vulns can be exploited locally without containers.

zlynx 9y ago

There are dangerous things that you can allow Docker to do. But if you don't do those things, it is pretty difficult to break out of a container. Redhat has been especially good here, with not allowing anyone but host-root to connect to Docker and using SELinux and seccomp filtering. With those working, it doesn't matter if your container mounts a host filesystem since it won't have the correct SELinux roles and types anyway. Many people claim that ruins Docker, since now you can't use Docker from within Docker. But that's the price you pay for security. I believe that with the correct precautions, a Linux container is just as safe as a jail or zone. Perhaps the problem is just how easy it is for a sysadmin to put holes into the containers that ruin the security.

s_kilk 9y ago
> since now you can't use Docker from within Docker. Docker-in-docker is a trashfire that barely works anyway, it's no real loss.
- bboreham 9y ago
  Think you might be talking about running the Docker daemon inside Docker, which is a different thing from just calling Docker from a container.
  - s_kilk 9y ago
    Ah, you're right. The latter is actually a pretty cool solution, I've had great success with using it to spawn what are essentially sibling containers.
mirashii 9y ago
> Perhaps the problem is just how easy it is for a sysadmin to put holes into the containers that ruin the security. I think there's a bit more to it than that. For some examples of other reasons people might be wary vs zones: docker itself is still a daemon that runs as root, combining a large number of different functionalities which require root access into a single binary with a large attack vector and a lot of code which doesn't need to be privileged. While isolation of responsibilities of docker has begun, even their own security page [1] admits that there's a long way to go here. Zones are, as many of the articles in this thread point out, a first class feature designed and implemented. What docker/"containers" allow you to do is the culmination of many building blocks which have been incrementally added to the Linux kernel. Some of those have been pretty recently, and without an overall design, their interactions with other portions of the Linux kernel or other components of the system have often been surprising and led to a number of security issues over time. In comparison, both the code and the design of the system are relatively young. A good example of this can be found at [2], which ends with the following very apt quote: > Why is it that several security vulnerabilities have sprung from the user namespaces implementation? The fundamental problem seems to be that user namespaces and their interactions with other parts of the kernel are rather complex—probably too complex for the few kernel developers with a close interest to consider all of the possible security implications. In addition, by making new functionality available to unprivileged users, user namespaces expand the attack surface of the kernel. Thus, it seems that as user namespaces come to be more widely deployed, other security bugs such as these are likely to be found. It might also be interesting to read [3], which is already showing that 3.5 years later, user namespaces are still a breeding ground for security issues that lead to privilege escalation. [1] https://docs.docker.com/engine/security/security/#related-information https://docs.docker.com/engine/security/security/#related-in... [2] https://lwn.net/Articles/543273/ https://lwn.net/Articles/543273/ [3] https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespacesWhySecurityProblems https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespace...

rodgerd 9y ago

The fact this is the top-rated comment really does say a lot about the technical literacy of the newsy audience.

unethical_ban 9y ago
Multiple explanations, not all of which need to be the case: * Not everyone needs or is an expert on containers, just as not everyone is knowledgable about the TCP stack, dynamic routing, assembly optimization, or name your topic. * It's a true and well-stated comment in itself and deserves to be recognized, even if many already know it.

rjzzleep 9y ago

It's just sad to watch this. the fact that the whole root zone etc. is just built right into every part of the os is amazing. And yet you have a bunch of companies just stroking their egos. I looked at the illumos-gate and smartos contributors as brendan suggested and there isn't much. I wonder if adding a proper wifi stack and commodity hardware supported would have helped. Maybe it's just wishful thinking but I thought it would have been nice for cheap routers and home nas. The fact that there is so little documentation also probably didn't help it

ryanlol 9y ago

... Precisely none of these are technologies that you should use to "safely" run multiple things on the same hardware.

DCKing 9y ago

I'm not sure what you mean here. Do you mean that: 1) There are known ways to perform Docker escapes on any or some common Docker setup. You could write a Docker escape binary or script today and it would not be a zero day. That's just the way Docker is. -or- 2) You simply have less faith in the ways Docker performs isolation. One could write a Docker escape exploit and it would be a zero day, but you expect there to be more of such zero days in Docker than in Jails/Zones. ? If 1) I'd be really interested in seeing it and if 2) I'd like to know more about what additional levels of isolation jails and zones (and LXC?) perform.

mirashii 9y ago
I've expanded a little bit more in another comment here, but I think 2) is less a case of any fundamentally different level of isolation, but more a maturity of design and implementation. While Zones were designed as first class, containers were not, they're built out of a variety of other building blocks, which while they may be more powerful primitives, have seen less review of design and implementation and exposed a large attack space on the kernel. User namespaces are the prime example, possibly because they are the largest/juiciest new target, but I expect we'll see more with time.

Spooky23 9y ago

Linux containers are very similar to Zones. I doubt you would choose between the two technologies based on security.

raesene9 9y ago

I'd be very interested to hear details of exactly how you would suggest, if I understand you correctly, that any Linux container can be broken out of. With user namespacing in use (available in Docker since 1.12) I'm not currently aware of any trivial container-->host breakouts or container --> container breakouts. There are information leaks from /proc but they don't generally allow for breakout, and in general Dockers defaults aren't too bad from a security standpoint. The only exception for the general case is, I'd say, the decision to allow CAP_NET_RAW by default, which is a bit risky.

Hello71 9y ago
https://google.com/search?q=user+namespace+vulnerability https://google.com/search?q=user+namespace+vulnerability https://lwn.net/Articles/543273/ https://lwn.net/Articles/543273/ https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespacesWhySecurityProblems https://utcc.utoronto.ca/~cks/space/blog/linux/UserNamespace...
- raesene9 9y ago
  Right so each of those are specific vulns. like all code gets, and not a systemic "linux containers aren't a security boundry" as suggested by the OP, which was the point I was asking for more info. on. All code has bugs, some of those are security bugs. There's a big difference between "if you haven't patched or I have a 0-day I can compromise you" and "no matter how well patched you are this isn't a security boundry so it can be bypassed" My reading of the top comment was it was suggesting the latter with regard to Linux containers, and I'm not sure that's true.
  - openasocket 9y ago
    Yes, but certain things tend to wind up with more security bugs than others, due to attack surface and the like. For instance, you tend to see browser exploits, SSL exploits, and privilege escalation attacks a lot more often than OS-level exploits, or hypervisor vulnerabilities. It's not that Docker is a gaping security hole, it's just not something I trust as much as the Linux Kernel or Xen. I probably trust it about as much as I trust a well-updated web browser. It's suitable for everyday use, but I don't click the link on the phishing or spam email just to see what happens.

vishvananda 9y ago

> Docker is basically the equivalent of a sign which says: "don't walk on the grass" as opposed to an actual wall which FreeBSD jails and Solaris zones have. I think this is dramatically overstating the risks. It is possible to run containers securely, it is just much more difficult to secure containers on linux than on BSD or Solaris. It is significantly difficult to break out of a properly configured container (using user namespaces, seccomp, and selinux/apparmor), and I know of no cases where it has been done successfully. I still separate tenants onto VMs because I don't want to be the first example of a breakout, but I don't think people who isolate with containers are crazy, just a little less risk-averse.

solatic 9y ago
> I think this is dramatically overstating the risks. It is possible to run containers securely, it is just much more difficult to secure containers on linux than on BSD or Solaris. The more difficult it is for sysadmins to harden their Docker setup, the less credence can be given to the claim that Docker is designed for security isolation. In the real world, security compromises happen far more often because of misconfigured setups, not because of zero-day exploits. This is why it's important for software in general to be shipped with secure defaults. I can't remember the source, so I'll paraphrase, but a rather wise guy once said: "I don't care how hard it is to break a hardened setup - what I'm concerned about is how easy it is to harden." Out of the box, Docker is designed to solve deployment problems, not security problems. And that's a crucial distinction.

e12e 9y ago

> Linux containers are not meant as security boundaries (...) > You can't run multiple docker tennant's safely on the same hardware. Docker is basically the equivalent of a sign which says: "don't walk on the grass" as opposed to an actual wall (...) I agree, but it's a strange way to frame it - the technology is lxc - and lxc (along with some enabling technologies and tools) do have, and has a history of, a focus on being a real boundary. docker has never (does now?) claimed, or implemented - or been about security boundaries. Stretching the metaphor, docker is using tar to package dependencies in a snapshot, and using plain chroot to run "containers" - even when jails are available. In terms of marketing, "Linux containers" might mean "docker" - but in technology (as contrasted with zones, jails) that's not quite right. So yes, "docker is not about security", lxc&friends maybe not quite equivalent to modern jails - but new ways of running "docker containers", like in actual vms - certainly can blend some convenience/popularity and security.

IgorPartola 9y ago
I am confused. I thought Docker was no longer based on LXC. Am I wrong on this?
- e12e 9y ago
  The whole story is somewhat long and complicated - I think it was roughly openvz (patch-set, out-of-tree for Linux "jails" > lxc > [docker enters the picture] > as more features for isolation are merged in mainline (namespaces ++) it means docker is no longer based on the same subset of features that the lxc project uses. I'm sure someone will chime in with an updated family tree of Linux chroots, capability frameworks and process isolation features. [ed: i believe one source of confusion is that docker started with (userspace part of) lxc as its only driver, and now docker-the-binary makes system calls directly, and avoids lxc-the-userspace-toolset - but they employ a mish-mash of kernel features, many-of came from the lxc project (on the kernel side)?]

emmelaich 9y ago

Openshift give you a free container with no more id than an email address. So clearly it can be made secure. Though I admit this would not be core docker stuff; more like selinux and other controls.

hacknat 9y ago

Linux does offer enough primitives to completely sandbox processes, as Zones and Jails did/do. The problem is that docker didn't implement all of those primitives right away, the biggest being user namespacing, which it didn't add until shockingly late in its development lifecycle. So, yes you can completely sandbox a "container", just be prepared to put in some work (SELinux, AppArmor, user namespaces, and reviewing the defaults capabilities quite carefully).