7 ms·

Containers are not only a solution for dependencies. It's also protection boundary.

by chmike 9y ago

neilwilson 9y ago
It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. We just didn't have a massive PR budget
- pjmlp 9y ago
  chroot only protects the file system, sandboxes are much more than that.
  - dijit 9y ago
    BSD Jails and Solaris Zones then. Everything old is new again, this time with an orchestration layer.
    - jamespo 9y ago
      Some would say the orchestration layer is quite important
      - betaby 9y ago
        And people were running cfengine inside FreeBSD jails and Linux vservers in early 2000 already.
        pmoriarty 9y ago
        Wow, and I thought I was the only one who remembers Linux vservers. Whenever I tell people I was using them 15 years ago, people look at me like I'm crazy. I was beginning to think I dreamed it all. Now here's Docker getting mountains of press for seemingly reinventing the wheel. But, to be fair, cgroups didn't exist back in the days of Linux vservers, so there was no easy way to constrain per-vserver resource use as there is now, the isolation wasn't as complete as with Docker, and there was no use of layered filesystems so you couldn't build up a Linux vserver layer by layer as you can a Docker container. It was still very useful back then, though. Way ahead of its time, and it's a shame most people never knew it even ever existed.
    - pjmlp 9y ago
      That I agree with, but then the best example are mainframe virtualization mechanisms. :) On UNIX world older examples than the ones you provided, would be HP-UX vaults and Tru64.
    - manigandham 9y ago
      Sure, but at some point it goes from niche to mainstream and that matters. Plus the docker registry model is a big deal that we didn't have before. Having a universally accessible way to just download a container and run it is arguably the secret to success this time around.
- signa11 9y ago
  > It's just a process with a fancy chroot. and also namespaces for file-system, network etc. etc.
- mschuster91 9y ago
  > It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. You can easily break out of a chroot jail: http://pentestmonkey.net/blog/chroot-breakout-perl http://pentestmonkey.net/blog/chroot-breakout-perl Thats not possible in Docker (okay, it is if you're running a container in privileged mode but that's another can of worms and you shouldn't do it unless absolutely neccessary). Also, Docker gives you networking isolation and especially RAM/CPU usage limitation, which is a real headache doing with chroot.
  - xorcist 9y ago
    > Thats not possible in Docker Believe this at your own peril.
    - mschuster91 9y ago
      At least right now, I do not know of a way to break out of a Docker container and the last bug I know of was fixed in 2014 (https://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ https://blog.docker.com/2014/06/docker-container-breakout-pr...). The only ways I know of that can be used to jailbreak are, as documented on https://security.stackexchange.com/a/153016 https://security.stackexchange.com/a/153016: kernel vulns (which are not inherent to Docker, and can hit you on any kind of Linux environment as soon as you achieve RCE in a hosted application), running a container with --privileged, and being careless with bindmounts - either by bind-mounting /dev, /proc and friends which you shouldn't do in any case unless you're aware of the pitfalls or by bind-mounting the Docker socket file. The latter is something that I see far too often (especially with docker-in-docker setups for Jenkins slaves), but if you're avoiding this, you're safe from that vector.
      - xorcist 9y ago
        Docker is comparable to a chroot in this regard. You can not break out of a chroot either, unless you are being careless with super user privileges or bind mounts. Which (unsuprisingly) people are, and that's why it's generally not recommended to use chroot alone for security. Not because chroot somehow is insecure or doesn't work as intended. Docker for the longest time didn't even try to constrict the root user. Later versions does, but the results will vary depending on your configuration. That's why the Docker documentation states it should not be depended on for security. It is wise to heed that recommendation.

Containers are not only a solution for dependencies. It's also protection boundary.

by chmike 9y ago

Containers are not only a solution for dependencies. It's also protection boundary.

It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. We just didn't have a massive PR budget

pjmlp 9y ago
chroot only protects the file system, sandboxes are much more than that.
- dijit 9y ago
  BSD Jails and Solaris Zones then. Everything old is new again, this time with an orchestration layer.
  - jamespo 9y ago
    Some would say the orchestration layer is quite important
    - betaby 9y ago
      And people were running cfengine inside FreeBSD jails and Linux vservers in early 2000 already.
      - pmoriarty 9y ago
        Wow, and I thought I was the only one who remembers Linux vservers. Whenever I tell people I was using them 15 years ago, people look at me like I'm crazy. I was beginning to think I dreamed it all. Now here's Docker getting mountains of press for seemingly reinventing the wheel. But, to be fair, cgroups didn't exist back in the days of Linux vservers, so there was no easy way to constrain per-vserver resource use as there is now, the isolation wasn't as complete as with Docker, and there was no use of layered filesystems so you couldn't build up a Linux vserver layer by layer as you can a Docker container. It was still very useful back then, though. Way ahead of its time, and it's a shame most people never knew it even ever existed.
  - pjmlp 9y ago
    That I agree with, but then the best example are mainframe virtualization mechanisms. :) On UNIX world older examples than the ones you provided, would be HP-UX vaults and Tru64.
  - manigandham 9y ago
    Sure, but at some point it goes from niche to mainstream and that matters. Plus the docker registry model is a big deal that we didn't have before. Having a universally accessible way to just download a container and run it is arguably the secret to success this time around.
signa11 9y ago
> It's just a process with a fancy chroot. and also namespaces for file-system, network etc. etc.
mschuster91 9y ago
> It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. You can easily break out of a chroot jail: http://pentestmonkey.net/blog/chroot-breakout-perl http://pentestmonkey.net/blog/chroot-breakout-perl Thats not possible in Docker (okay, it is if you're running a container in privileged mode but that's another can of worms and you shouldn't do it unless absolutely neccessary). Also, Docker gives you networking isolation and especially RAM/CPU usage limitation, which is a real headache doing with chroot.
- xorcist 9y ago
  > Thats not possible in Docker Believe this at your own peril.
  - mschuster91 9y ago
    At least right now, I do not know of a way to break out of a Docker container and the last bug I know of was fixed in 2014 (https://blog.docker.com/2014/06/docker-container-breakout-proof-of-concept-exploit/ https://blog.docker.com/2014/06/docker-container-breakout-pr...). The only ways I know of that can be used to jailbreak are, as documented on https://security.stackexchange.com/a/153016 https://security.stackexchange.com/a/153016: kernel vulns (which are not inherent to Docker, and can hit you on any kind of Linux environment as soon as you achieve RCE in a hosted application), running a container with --privileged, and being careless with bindmounts - either by bind-mounting /dev, /proc and friends which you shouldn't do in any case unless you're aware of the pitfalls or by bind-mounting the Docker socket file. The latter is something that I see far too often (especially with docker-in-docker setups for Jenkins slaves), but if you're avoiding this, you're safe from that vector.
    - xorcist 9y ago
      Docker is comparable to a chroot in this regard. You can not break out of a chroot either, unless you are being careless with super user privileges or bind mounts. Which (unsuprisingly) people are, and that's why it's generally not recommended to use chroot alone for security. Not because chroot somehow is insecure or doesn't work as intended. Docker for the longest time didn't even try to constrict the root user. Later versions does, but the results will vary depending on your configuration. That's why the Docker documentation states it should not be depended on for security. It is wise to heed that recommendation.