Sandboxing, virtualisation and containers

A sandbox limits what code can call, and raises the cost of escape without removing it

Running someone else’s code is not optional. A browser runs scripts from sites it does not control, a host runs virtual machines it did not build, and a build pipeline runs containers packaged by someone else’s Dockerfile. Sandboxing, virtualisation and containers run that code anyway, inside a boundary tight enough that misbehaviour stays the code’s problem rather than the host’s.

A sandbox is a restricted execution environment: code inside it gets a limited API rather than direct access to the host. The lecture’s example is the Java applet, now mostly historical, which had no access to the local hard disk (or at most a restricted temporary directory) and could only talk back to the host it was loaded from, the same-origin rule that reappears in the browser. JavaScript in a page is sandboxed the same way, and Chrome gives each tab its own operating-system process, so a script that hangs one tab does not take the browser down.

Sandboxes are hard to secure but can be broken out of: a flaw in the sandbox’s own implementation, or in the limited API it exposes, lets code reach further than the boundary intended, acting with the host’s privileges instead of its own. The restricted API and per-tab isolation are not formal access control and not unbreakable, but the effort they demand raises the cost of an attack without removing the possibility of one.

Virtualisation isolates a whole guest OS, at three depths

Virtualisation takes the idea up a level: instead of restricting one piece of code inside a shared operating system, it gives a whole guest operating system hardware that only appears to be its own. IBM invented the technique in the 1960s: VM/370 partitioned a single physical machine into several virtual ones. A VM lets software run when the environment it was written for no longer exists, and at the client end it is how one operating system runs on another, such as Windows on macOS.

The depths differ in how much is emulated. Full virtualisation emulates the hardware completely, even across a different architecture, so an unmodified guest OS runs without knowing anything has changed. Para-virtualisation asks the guest OS to cooperate with the hypervisor, trading complete emulation for a guest that must support being virtualised. Containers and jails are lighter again: they isolate an application’s environment without emulating a separate machine underneath it at all.

Compare

Full virtualisation

Emulates the hardware completely, including across a different architecture. The guest operating system runs unmodified, with no indication anything has changed underneath it.

Para-virtualisation

The guest operating system has to support being virtualised and cooperates with the hypervisor directly, trading full hardware emulation for that cooperation.

A hypervisor manages and runs the VMs, for both full and para-virtualisation, with hardware support at ring -1, below the ring 0 an operating system kernel normally occupies. VirtualBox, VMWare, Xen and QEMU are the lecture’s examples.

Virtualisation was never built for access control, but the effort needed to break out of a VM does the same job: it raises the bar for an attacker. Two limits matter. A VM does not perfectly imitate a real environment, so its execution can be detected from inside, and malware that checks can change its behaviour rather than reveal itself somewhere built to analyse it. And hypervisors have vulnerabilities, so a guest can exploit one to reach the host or a neighbouring VM (a VM escape). The lecture’s advice: keep hypervisor software up to date, and do not rely on virtualisation as the only defence.

Exam detail

VM detection is not the same thing as a VM escape, and an answer that conflates them loses marks. Detecting that it is inside a VM only lets malware change what it does next, refusing to run its payload when it suspects it is being analysed, for instance. Escaping the VM is a separate, harder problem: reaching the hypervisor or host from inside the guest.

Each layer isolates what runs above it from what runs below, and none of it is designed primarily as access control — hardware rings, hypervisors, process isolation, containers and sandboxes are re-purposed for it. Break one layer and the ones below still hold: a compromised sandboxed tab should not touch the container's other processes, and a compromised container should not touch the host OS. The layer that fails least gracefully is the top of this list, hardware — breaking out of a hypervisor or defeating memory protection removes every layer above it at once.

Containers are lighter than VMs, and Docker’s root daemon is the catch

Docker began as a tool for continuous integration and delivery, not isolation. It builds images, packages of an application together with the libraries it needs, and spins containers up from them quickly and cheaply. Orchestration systems such as Kubernetes manage large numbers of containers as a group. Docker abstracts over the host OS’s native jail mechanism, so the same image behaves the same way across several OSes.

Containers sandbox the application inside them: one container cannot talk directly to an app in another. But the component that starts and stops containers, the Docker daemon, runs as root. Any user able to start or stop a container is interacting with a root-privileged process, so compromising that interaction point compromises root on the host, not just the container. Container separation raises the bar the way a sandbox or VM does, but it is no fix for the daemon’s own root privilege; containers were not designed as an access-control mechanism.

Pitfall

Do not write that Docker containers are as isolated as separate virtual machines. A container shares the host kernel with every other container and with the root daemon that manages them; a VM does not share a kernel with its host at all. The lightness that makes containers fast to start is the same thing that makes their isolation shallower than a VM’s.

Recall

Why is Docker's root-privileged daemon a security concern, specifically?

Not because root exists somewhere on the system, but because ordinary container operations, starting or stopping a container, go through that daemon. Anyone able to perform those ordinary operations is talking to a process running as root, which widens the attack surface beyond what container isolation alone suggests.