Recently, I have heard of a new virtualization tech called containers. Suppose the container has been compromised, does this mean the host is also compromised (since the container is a process on a host)? In terms of security, is a VM (virtual machine) more secure than containers?

  • 16
    This comic was hanging on the wall at my last gig, for a reason. Commented Dec 17, 2018 at 14:16
  • 8
    If the vulnerability is in the application code, a container provides pretty good protection. If, however, the vulnerability is in the kernel, you basically lost and would better have used a VM.
    – caw
    Commented Dec 17, 2018 at 18:00

2 Answers 2


If the kernel is compromised in the container, the host is compromised.

Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual machines. That does not mean that virtual machines can't be hacked. They are just not quite as bad.

If the kernel is exploited in a virtual machine, the attacker still needs to find a bug in the hypervisor. If the kernel is exploited in a container, the entire system is compromised, including the host. This means that kernel security bugs, as a class, are far more severe when containers are used.

Containers are often implemented by using namespaces:

A namespace wraps a global system resource in an abstraction that makes it appear to the process within the namespace that they have their own isolated instance of a global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes.

Unfortunately, Linux namespaces typically expose a much greater attack surface area from the kernel. Many kernel vulnerabilities are exploitable in namespaces. While not every container solution uses Linux namespaces, they all use the same kind of technology, with the same security issues. Some containers, like Docker, are capable of making use of a syscall filtering framework called seccomp to reduce the attack surface area of the kernel. This is an improvement, but isn't enough.

If you are not using containers and have no need for (unprivileged) user namespaces, you have the option to disable them by setting user.max_user_namespaces = 0 to improve security.

From Daniel Shapira:

[...] kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t sufficient.


Because containers are not as isolated as VMs, yes, in one way they are less secure. See forest's answer.

Having said that, I think it's worth noting that containers also provide some some benefits from a application security perspective. Because they typically run a single process they limit the attack surface, there's no cron monitor or ssh daemon running inside the container, for example. Container images are immutable: on restart they load from the original binaries. You can't overwrite the application. Most container technologies also allow precise control over what ports are open and to whom. You can have a container for a DB that cannot be accessed from anything other than your other containers.

All of this assumes that these features work as advertised and do not have flaws, of course. And if an attacker manages to escape from the container, none of the above applies. It adds a bit of overhead but a belt and suspenders approach is possible: containers on top of VMs.

  • 2
    Well you can also divide your VM in multiple sub networks, enable local firewall to filter port and so on. To me containers are at the very least an interesting opportunity when you want to isolate stuff and those stuff aren't worth a full VM configuration. I'd consider to put entry points in a VM and the reste eventually only in containers. With a strict watching on what happens in the VM (like typical monitoring of any files update of the system)
    – Walfrat
    Commented Dec 18, 2018 at 10:23
  • @Walfrat You can do a lot to reduce the attack surface of a VM running a full linux distro, for sure. And maybe if you are a guru, you might even get it right. For docker, at least, the default is 'nothing available'. Everything has to be explicitly brought in and enabled. If you want to setup say a cluster of webservers that talk to a dedicated back-end, you can't hide the DB from other hosts on the network using VM configurations alone. Doing this in something like kubernetes is a trivial configuration.
    – JimmyJames
    Commented Dec 18, 2018 at 14:21
  • I guess so, I'm from the development side so I'm far from off what system guys really can do or how easy / hard it can befor people knowing the right tools (or if there is one). My comment is what I understood in the context of the current question, which is if you really want high security without eventually doing too much security (and costs), you might at least invest specially on the entry point, and so put that in a VM under strict control and only allowing the minimum interaction with the rest of the system. If I were do to it myself, I just won't, I don't have the skills for that.
    – Walfrat
    Commented Dec 18, 2018 at 15:12
  • @Walfrat I think you are speaking to the heart of my main point here. Application people like you and me are typically don't have the skills to secure the host environment. Containers let developers specify what their application needs from the environment in a transparent way. This lets the experts secure the host in a more or less application agnostic way. I see a lot of opportunity for people who can manage and secure container environments.
    – JimmyJames
    Commented Dec 18, 2018 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .