[feld]

Virtualization is not a security implementation. I've been saying this for years and I'll continue to keep my tinfoil hat on.

As Theo DeRaadt said

  You are absolutely deluded, if not stupid, if you think that 
  a worldwide collection of software engineers who can't write 
  operating systems or applications without security holes, 
  can then turn around and suddenly write virtualization 
  layers without security holes.

I caught someone in a meeting last week trying to sell another employee on the security benefits of virtualization and I nearly bit my tongue off.

[tptacek]

That ship has already sailed, so much so that real companies are willing to execute hostile code inside Docker instances; Docker isn't even virtualized.

Given that virtualization is the de facto standard deployment technology for the majority of all new applications, it's worth knowing the specific limitations.

[jewel]

Virtualization does offer additional security if it's used to isolate things that otherwise would have been running on the same host. For example, at my old job we used OpenVZ to isolate wordpress, twiki, and roundcube, whereas historically we would have had them all installed on the same webserver.

I think this is the original source of the confusion, which has since disseminated to those who don't understand the nuances and think that virtualization adds security in every case.

The PCI DSS requires that each server just has one purpose. I was surprised when in a later version they explicitly allowed virtualization as a way to comply with that requirement.

[SixSigma]

same webserver would have had users and groups - you have bought complexity instead of using the existing mechanisms

[jude-]

While I agree with Theo in principle, it sounds like he's precluding the possibility that one can create a virtualization layer with formally-proven correctness guarantees (be it a hypervisor, an OS, or an application VM). For example, seL4 is proven to be free of many common types of bugs (NULL pointer dereferences, use-after-free errors, buffer overflows, etc.) that lead to security holes. AFAIK, there is no such proof for OpenBSD.

I'm not trying to suggest that a virtualization layer with formal proofs of correctness is a security panacea (it's not--correctness is necessary but not sufficient for security). What I am suggesting is that there is a way forward to developing secure virtualization layers.

If anything, this paper suggests to me that it would be best if the lowest layer in the stack (be it the OS or the hypervisor) implemented some of the crypto primitives on behalf of the applications. I can't see any other way to run them while also guaranteeing that (1) their execution is correct with the specification, (2) they run in full isolation from one another, and (3) they avoid timing attacks and whatever side-channels we can think of.