Hacker News Reader

Comment by prottmann | Hacker News Reader

The obvious question is: what's the real problem with that?

A container is a container, as long as docker itself has not bug, the container can only harm the containers content.

Most problems exists in the custom created software in the container (e.g. web-services with bugs, backdoors, ....), this will be a problem for Docker, VMs, Real-Servers, whatever too.

The real problem is the interoperability of different container, if you link the whole data, without any audit, to another container, you can have a problem, but this problem is not docker specific.

View on HN

>> A container is a container, as long as docker itself has not bug, the container can only harm the containers content.

Presumably a container has network access of some sort? Malicious code could start probing and attacking anything exposed that way.

>> this will be a problem for Docker, VMs, Real-Servers, whatever too.

The implication is that you wouldn't get into this situation with a 'Real-Server' so easily, because you wouldn't just download an image and run it, without having an update/patch strategy or having much more idea of what's going on inside it.

But you assume that a container HAS full network access. A firewall must be configured, but a firewall must be configured for a VM too. My point is, that their is not so a huge difference for production systems.

>> But you assume that a container HAS full network access.

No, I'm presuming it has some sort of network access, a malicious container could (for instance) still probe other containers for vulnerabilities, serve malware etc etc without full network access.

>> A firewall must be configured, but a firewall must be configured for a VM too. My point is, that their is not so a huge difference for production systems.

If you're downloading VM images from somewhere and running them without checking what's in them you'll run into the same problem, sure.

The problem being pointed out here is that when applications are bundled outside of the purview of a packager like debian you -

  - don't have as much trust in the origin of the app
  - don't have an easy way to keep up on library patchlevels etc for security

You seem to ignore or downplay all the other ways a container can cause problems, including but not limited to:

- Being a backdoor to the rest of your network (sniffing network traffic, or more simply reverse ssh-tunneling to an outside server)

- All the various "fun" botnet-related activities (spam being the king here)

- Actively serving malware to the rest of your network.

EDIT: Formatting, and well, others answered your question less specifically but more eloquently.

> A container is a container, as long as docker itself has not bug, the container can only harm the containers content.

So given that there are no bugs and as long as the Linux kernel is free from local privilege escalation exploits. That seems long odds to trust in.

The same trust i have in a VM or a RM.

Not true if the software in your VM or RM is managed by a package manager and comes from a place that issues security updates, patches etc.

One of the criticisms in the article is that much of what's going on now, either with containerisation or weird build systems like Hadoop's, misses out on this.

Reply on news.ycombinator.com