<p>Containers isolate an application on a shared OS, VM's isolate an OS on shared hardware. With those different levels of abstraction, you have different exploits and protections.</p>

<p>A successful kernel level exploit on a container will affect the shared kernel, and therefore breakout of the container isolation. Think meltdown and spectre.</p>

<p>A successful VM driver exploit could break out of the VM to the hypervisor running the VM's. I've heard of exploits on things like the floppy driver in VMs. These are much more rare than kernel exploits, so I'd give the advantage to VM's here.</p>

<p>It is possible to change the container runtime to spin up containers in small VM's. Projects like Kata Containers are working on this. So you could get the security of VM's while still getting some of the features of containers.</p>

<p>Containers do have a huge different advantage over VM's. They run in a minimal environment with reduced capabilities, seccomp, and optionally selinux/apparmor configured. You can lock down that environment in ways you couldn't easily lock down a VM, with a read-only filesystem, and not including any of the tools like shells, interpreters, and libraries that an attacker may need to exploit your system to try attacking the kernel or horizontally pivot their attack.</p>

<p>As a result, there's no clear winner. The best answer is likely a combination of both, running a handful of containers with similar security requirements on their own VM.</p>

CC BY-SA 4.0
2018-07-05T13:43:37.767Z
thank you! but then, given that that only one binary/library in container appears vulnerable to a kernel level attack, does this mean that all folks who use K8s "live" with this risk? (as K8s uses containers as well) (not sure whether it's worth of a separate question)
Ta Mu
CC BY-SA 4.0
2018-07-05T13:52:37.860Z
Not sure I follow the question since k8s can schedule containers to run on different VMs if needed for additional security. K8s is little more than a scheduler/orchestration tool, it's up to you to organize the legos underneath that it runs. Not following what binary inside a container that is vulnerable that wouldn't be vulnerable inside a VM, usually it's the other way around since you can lock down an app inside a container in ways you can't easily do in just a VM.
BMitch
CC BY-SA 4.0
2018-07-05T13:31:42.520Z
2018-07-05T13:31:42.520Z
BMitch
<p>What is exactly the (higher) vulnerability at least theoretically of a container compared to VM? given, all security recommendations are implemented (like, user context is root, no host sensitive volumes are mounted, tuned capabilities..).</p>

<p>How differently can an exploit compromise a container via network interface other than a VM? Could a "bad" TCP package force Docker daemon to create a container with root rights? </p>

<security><devsecops><virtualization>
Possibility of container breakout compared to VM (virtual machines)
Ta Mu
# Possibility of container breakout compared to VM (virtual machines)

(Asked by: username_0 on 2018-07-05)

What is exactly the (higher) vulnerability at least theoretically of a container compared to VM? given, all security recommendations are implemented (like, user context is root, no host sensitive volumes are mounted, tuned capabilities..).

How differently can an exploit compromise a container via network interface other than a VM? Could a "bad" TCP package force Docker daemon to create a container with root rights?

**Tags:** security, devsecops, virtualization


---

## 1 answers

### Answer by username_1 on 2018-07-05. Score: 2

Containers isolate an application on a shared OS, VM's isolate an OS on shared hardware. With those different levels of abstraction, you have different exploits and protections.

A successful kernel level exploit on a container will affect the shared kernel, and therefore breakout of the container isolation. Think meltdown and spectre.

A successful VM driver exploit could break out of the VM to the hypervisor running the VM's. I've heard of exploits on things like the floppy driver in VMs. These are much more rare than kernel exploits, so I'd give the advantage to VM's here.

It is possible to change the container runtime to spin up containers in small VM's. Projects like Kata Containers are working on this. So you could get the security of VM's while still getting some of the features of containers.

Containers do have a huge different advantage over VM's. They run in a minimal environment with reduced capabilities, seccomp, and optionally selinux/apparmor configured. You can lock down that environment in ways you couldn't easily lock down a VM, with a read-only filesystem, and not including any of the tools like shells, interpreters, and libraries that an attacker may need to exploit your system to try attacking the kernel or horizontally pivot their attack.

As a result, there's no clear winner. The best answer is likely a combination of both, running a handful of containers with similar security requirements on their own VM.

> **Comments:**
> **username_0**: thank you! but then, given that that only one binary/library in container appears vulnerable to a kernel level attack, does this mean that all folks who use K8s "live" with this risk? (as K8s uses containers as well) (not sure whether it's worth of a separate question)  
> **username_1**: Not sure I follow the question since k8s can schedule containers to run on different VMs if needed for additional security. K8s is little more than a scheduler/orchestration tool, it's up to you to organize the legos underneath that it runs. Not following what binary inside a container that is vulnerable that wouldn't be vulnerable inside a VM, usually it's the other way around since you can lock down an app inside a container in ways you can't easily do in just a VM.  

---

