We don’t need no virtualization

22 points by Mordo


repnop

some thoughts from someone who is passionate about capability systems and software isolation:

virtualization and containerization are mainly orthogonal concepts, and their use cases may or may not overlap depending on what you’re doing. containers are used, generally today, as a mechanism, not for sandboxing/isolation, but for software distribution. to hammer this point in, you have to do extra work to secure your containers! (see things like Google’s distroless images which very few projects use) they are not a secure sandboxing environment and have escape mechanisms (if you mount e.g. a docker socket into a container that run as root, your host is able to be 100% compromised).

virtualization on the other hand, is primarily about software isolation and resource partitioning, allowing you to securely run applications which need root/admin access without worrying about that compromising the host machine (minus CVEs and the like, ofc) and running your whole system out of RAM/disk space. but you can use virtualization as a mechanism for distributing software as well, it’s more annoying though. (for example, GitHub Enterprise is distributed as an OVF and expected to be run inside of a virtual machine).

more often than not, both of these concepts are used together. if you have a VPS (with emphasis on the P! containers don’t let you do things like AMD’s SEV), you’ll likely use a container runtime like docker or podman to run software on the VPS, your provider is in no way going to allow you to run an unknown container on their host machines because that opens up way too many security risks!

so yes, we do need virtualization. operating system isolation is an extremely important component of modern computing, and containers, while useful, do not provide anywhere near the same guarantees as virtualization does.

now onto the topic of capability systems and language-native capability systems:

I think both of these are really where the vast majority of new system software should be heading, but due to historical reasons, struggle to reach mainstream computing in an effective way. the primary issue with this is made of two independent parts:

  1. you have operating systems which do not utilize capability-based security for their privilege management
  2. you have existing languages which do not have first-class in-language capability systems and allow for FFI

combine both of these together, and proper capability-based security doesn’t really get you much in practice. if your application is written in a capability-based language but has e.g. an arbitrary code execution vulnerability or allows for FFI to a non-capability-based language AND if the operating system doesn’t enforce capabilities, it’s more or less a convenience for the software author and not an actual security mechanism.

now, if the operating system enforces capability-based security, this is where things get promising! it becomes much more difficult (and ideally impossible) to have privilege escalation vulnerabilities that allow for access to arbitrary parts of the system. you can then combine this with a capability-based security language to have actual guarantees about what kind of resources the application has access to, which is amazing!

does this negate the need for virtualization though? nope :) still necessary to run multiple guest OSs on a single host (which may not have capability-based security!). it also doesn’t entirely negate containers either, since as I mentioned earlier, they’re more useful for distributing software with complex dependency relationships, but capabilities allow you to provide more security guarantees than the current systems we have in place IMO.

bit of a wall of text, but hopefully it provides some interesting perspective :)