4 ms·

Why, exactly? The article's argument is that containerization limits the vulnerable area - even if an attacker gains root access to a container, they still can'

Why, exactly? The article's argument is that containerization limits the vulnerable area - even if an attacker gains root access to a container, they still can't do as much damage as they would had they gotten root access in a host machine. I don't mean to sound adversarial - but what's your counterpoint to that?

api 10y ago
Is that really true? I have always read that cgroups based containerization on Linux is kind of a joke and that root in the container more or less equals root on the host. Has there been significant improvement in this area lately?
- ralmeida 10y ago
  I'm not familiar with that perception, any good reads on that?
  - raesene9 10y ago
    tends to be much older articles that had that perception, pre userns, seccomp, extended cgroup support etc.
- wmf 10y ago
  The fix for that is user namespaces which is (finally) included in Docker. So yes, it has gotten better.
fapjacks 10y ago
There isn't one. It's just a narrative regurgitated by people with an axe to grind. The anti-Docker crowd. User namespacing arrived in 1.10, which brought a lot of great possibilities for further compartmentalization with it. Alpine is the default base image. Lots of great, positive changes have gone into this blog post.
- officialchicken 10y ago
  > Lots of great, positive changes have gone into this blog post. I'm not sure I agree, I'd offer some improvements: - Gartner "studies" are usually paid advertisements - The comparison table is missing columns for DOM0/1 VM's and BSD jails - Encryption in-transit or at-rest isn't mentioned - Nothing about key management or key rotation - Non-mutable / exported log files aren't in the defaults
  - bigmac 10y ago
    Great points, we're working on a bunch of this stuff. Docker 1.12 in swarm mode, for example, does automatic key rotation and issuance of the TLS certs assigned to every node in the cluster. These certs are used for automatic TLS between every node in the control plane of the Docker Swarm. This is all automatic and transparent to the user -- no manual management of certificates is required. Now that we have cryptographic identities assigned to every node in the cluster we can use that to build secrets/key management in to the system. Additionally Docker 1.12 is swarm mode has overlay networking with encryption possible for container to container communications. In terms of logs, Docker supports log drivers that allow all logs within Docker containers to be exported to off-host logging services.
    - rmoriz 10y ago
      How is the overlay network encrypted? I couldn't find any information. https://github.com/docker/docker/issues/24253 https://github.com/docker/docker/issues/24253 says it's not encrypted by default and must be enabled manually.
      - bigmac 10y ago
        You're right -- it needs to be enabled manually using `--opt encrypted`. 1.13 is shooting for this to be the default.
codemac 10y ago
The bundling of all your software's dependencies into your container means that you can't upgrade 1 .so on a machine, and all software be updated. Great example recently was libgcypt's security bugs. You have to upgrade all containers, which requires figuring out which ones need upgrading. The concern isn't generally that someone will escalate and then delete some other container's filesystem.. it's that once they get remote execution in a container that has connections to your database, http to your discovery service etc, they can steal your customer information. I will say however that this post is showing that by using docker or frankly other well manicured execution enviroments, large swaths of attacks will hopefully not work (selinux & seccomp being great examples).
- riskable 10y ago
  Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application). They're also meant to be mostly immutable. So a vulnerability in a particular library that allows an attacker access to the container won't necessarily allow them to do much. The other benefit of short-lived containers is that any given vulnerability only lasts as long as the container (assuming you're rebuilding your image with the latest & greatest software/libs before each deployment). Whereas with a full OS/VM you have to find down time to patch that sucker and that might take a month or even a quarter or longer.
  - pmontra 10y ago
    I'm not sure I understand this. Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?
    - tayo42 10y ago
      Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...

api 10y ago

Is that really true? I have always read that cgroups based containerization on Linux is kind of a joke and that root in the container more or less equals root on the host. Has there been significant improvement in this area lately?

ralmeida 10y ago
I'm not familiar with that perception, any good reads on that?
- raesene9 10y ago
  tends to be much older articles that had that perception, pre userns, seccomp, extended cgroup support etc.
wmf 10y ago
The fix for that is user namespaces which is (finally) included in Docker. So yes, it has gotten better.

fapjacks 10y ago

There isn't one. It's just a narrative regurgitated by people with an axe to grind. The anti-Docker crowd. User namespacing arrived in 1.10, which brought a lot of great possibilities for further compartmentalization with it. Alpine is the default base image. Lots of great, positive changes have gone into this blog post.

officialchicken 10y ago
> Lots of great, positive changes have gone into this blog post. I'm not sure I agree, I'd offer some improvements: - Gartner "studies" are usually paid advertisements - The comparison table is missing columns for DOM0/1 VM's and BSD jails - Encryption in-transit or at-rest isn't mentioned - Nothing about key management or key rotation - Non-mutable / exported log files aren't in the defaults
- bigmac 10y ago
  Great points, we're working on a bunch of this stuff. Docker 1.12 in swarm mode, for example, does automatic key rotation and issuance of the TLS certs assigned to every node in the cluster. These certs are used for automatic TLS between every node in the control plane of the Docker Swarm. This is all automatic and transparent to the user -- no manual management of certificates is required. Now that we have cryptographic identities assigned to every node in the cluster we can use that to build secrets/key management in to the system. Additionally Docker 1.12 is swarm mode has overlay networking with encryption possible for container to container communications. In terms of logs, Docker supports log drivers that allow all logs within Docker containers to be exported to off-host logging services.
  - rmoriz 10y ago
    How is the overlay network encrypted? I couldn't find any information. https://github.com/docker/docker/issues/24253 https://github.com/docker/docker/issues/24253 says it's not encrypted by default and must be enabled manually.
    - bigmac 10y ago
      You're right -- it needs to be enabled manually using `--opt encrypted`. 1.13 is shooting for this to be the default.

codemac 10y ago

The bundling of all your software's dependencies into your container means that you can't upgrade 1 .so on a machine, and all software be updated. Great example recently was libgcypt's security bugs. You have to upgrade all containers, which requires figuring out which ones need upgrading. The concern isn't generally that someone will escalate and then delete some other container's filesystem.. it's that once they get remote execution in a container that has connections to your database, http to your discovery service etc, they can steal your customer information. I will say however that this post is showing that by using docker or frankly other well manicured execution enviroments, large swaths of attacks will hopefully not work (selinux & seccomp being great examples).

riskable 10y ago
Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application). They're also meant to be mostly immutable. So a vulnerability in a particular library that allows an attacker access to the container won't necessarily allow them to do much. The other benefit of short-lived containers is that any given vulnerability only lasts as long as the container (assuming you're rebuilding your image with the latest & greatest software/libs before each deployment). Whereas with a full OS/VM you have to find down time to patch that sucker and that might take a month or even a quarter or longer.
- pmontra 10y ago
  I'm not sure I understand this. Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?
  - tayo42 10y ago
    Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...