[jacques_chester]

> It's still containers.

The security profiles of containers and VMs, including kernel-based VMs, are different. VMs still have a significant edge, because the attack surface is smaller and doesn't have many competing missions.

[cyphar]

The attack surface of a container can be massively reduced with seccomp profiles -- there was a paper a few years ago which found that the effective attack surface of a hypervisor was about the same as the attack surface of a locked-down seccomp profile of a container (and LXC/Docker/etc already have a default whitelist profile which has in practice mitigated something like 90% of kernel 0days).

And let's not forget the recent CPU exploits which found that VMs aren't very separated after all.

The fact that Kubernetes disables this (and other) security features by default should be seen as a flaw in Kubernetes. (Just as some of the flaws of Docker should be seen as Docker flaws not containers-in-general flaws.)

[jacques_chester]

> The attack surface of a container can be massively reduced with seccomp profiles

Yes, though as capabilities are added to the kernel, the profiles have to be updated.

That said, VM or no VM, this should be done no matter what.

> And let's not forget the recent CPU exploits which found that VMs aren't very separated after all.

This is a nil-all draw in terms of the respective security postures, though.

[ryacko]

The economics agree, Zerodium pays as much for VM escape as for LPE. It does seem to be a bit of a low price though, $50,000.

[tptacek]

The attack surface argument is debatable, depending on how the system is designers, since virtualization introduces the hypervisor surface.

[halbritt]

The attack surface argument certainly is debatable.

I wonder how many multi-tenant workloads are actually at risk of an escape vulnerability. I wager that the multi-tenancy described in the article in the OP is actually disparate workloads across disparate teams in a particular enterprise where it seems (to me) fairly unlikely for someone with access to run a workload to also have the willingness to compile and run malicious code to take advantage of an escape vulnerability.

On the other hand, publicly available compute, i.e. AWS, GCP, Azure seems way more likely to be the subject of attacks from random malicious individuals seek to take advantage of an escape vulnerability if one existed.

[jacques_chester]

The hypervisor surface can be made smaller, since its major goal is to manage hardware resources. A kernel has the same mission, but also has a mission to provide a rich API for applications.

[raesene9]

it's not really as clear cut as that (IMO).

Shared kernel linux containers can be hardened to the point, where they likely have a smaller attack surface than a general purpose hypervisor (for example look at the approach that Nabla takes)

You then have the hybrid approach of gVisor, still containers, but smaller attack surface than the Linux kernel.

Of course this hardening approach can (and should be) applied to VMs too, which may tip the balance back to them, which is one reason that firecracker looks so interesting.