| Yep, VMs are safer than containers, because there is a larger barrier between the possibly malicious code running inside the VM than there is in the container context. A container is just another process, bound by limitations via namespaces and cgroups -- running on a shared kernel as a host. But don't take my word for it: > Simply put, containers are just processes, and as such they are governed by the kernel like any other process. Thus any kernel-land vulnerability which yields arbitrary code execution can be exploited to escape a container. To demonstrate this, Capsule8 Labs has created an exploit that removes the process from its confines and gives it root access in the Real World. Let’s take a look at what was involved. (I don't know much about capsule8 as a company is but that article[0] is pretty informative and seems spot on from what I read) If you can infiltrate a process (let's say a web server) running in a container and know a kernel exploit that can be used to get past these limitations (a "container escape"), then you can use them and get root on the main system. If that same process was running in a VM (without a container), you need to: - Infiltrate the process - Kernel exploit to gain root (assuming the program wasn't running under it) in the VM - Escape the VM (i.e. use the kernel or whatever else to actually break past the barriers of the hypervisor which was running the vm -- qemu +/- kvm, hyperv,etc) -- aka a "virtual machine escape"[1] - Gain root on the host system (assuming the process that spawned the hypervisor wasn't running as root) Generally, virtual machine security is pretty good these days, by virtue of being around longer and having more exposure and eyes looking for exploits. [0]: https://capsule8.com/blog/practical-container-escape-exercis... [1]: https://en.wikipedia.org/wiki/Virtual_machine_escape |