What’s the difference between sandboxes vs. containers?

VM sandbox security model

Sandboxing is, in essence, about creating a sequestered, isolated environment that you can use for security-specific purposes — e.g., FreeBSD. In the case of antimalware, for example, you might use an isolated sandbox to detonate a malware sample to see what it does. By running the suspected malware sample and observing what it does, you can observe empirically what the attack methodology is to see how you are being targeted. In the case of unknown software, you might use this method to determine if a file is safe to be run on a managed endpoint. If the software does not perform any malicious actions, it can get relayed to the end user. Likewise, in the case of a suspected malware sample, you might employ this technique to further study the malware. This can let you know if you are being targeted as part of a sophisticated campaign — such as a nation-state — or if you are just getting randomly targeted by bots or script kiddies.

Hypervisors provide two features that make this technique safer than would otherwise be the case. First, they enforce segmentation in a nonporous way. We employ virtualization in the modern environment in such a way that this segmentation boundary is paramount. Consider how many organizations would use multi-tenant IaaS if data could be stolen or attacks attempted across a VM segmentation boundary — for example, if one organization could steal data from, corrupt or otherwise attack other VMs on the same hypervisor. Second, hypervisors let us selectively throttle or block what the VM can do. For example, it can preclude a workload from sending or receiving data on the network or, using snapshots, can restore a corrupted VM to a known-reliable state.

Used in this way, VM-based sandboxing relies on multiple VMs to catch traffic as it ingresses and egresses the network and acts as a chokepoint for malicious activity detection. The goal of this kind of sandboxing is to take unknown files and detonate them within one of the VMs to determine if the file is safe for installation. Since there are multiple evasion techniques malware authors can use to make a file appear safe, this doesn’t always offer a foolproof solution, but does provide an extra layer of defense.

Container sandbox security model

The other approach we can use is software containers. There are multiple different models of implementation. Tools including Docker and Rocket create isolated application environments; the segmentation is enforced at the OS level — in this case, using Linux namespaces and cgroups. There are also container-based configurations built into certain OSes, like chroot jails in Linux or Windows Sandbox for Windows.

From a usage standpoint, you can earmark everything within the container as always untrusted, enabling you to create a separate teardown environment that will not affect the underlying host. In this use case, everything within that container is considered potentially dangerous. And the container doesn’t try to determine if a file is bad; it just contains malware activity from spreading or damaging the underlying host. For example, consider a situation where you are concerned about a user being exposed to drive-by downloads or other spurious activity on the web. One approach is to run the browser within an application sandbox and destroy the sandbox when the user’s browsing session is complete. Any potential malware the user has collected along the way is blown away along with the sandbox when it resets.

When used in this way, software containers don’t use signatures like an antivirus product. They do not prevent the attack from being successful. It’s just that the scope of the impact is constrained as the container is built around the specific application — the browser in the above example — to isolate attacks from occurring or spreading to other parts of the OS in the event that application is compromised.

In many ways, the container takes sandboxing to the endpoint in this approach. It’s not as worried about the content of a downloaded file as it is concerned about resetting the application to a known-good state after the user is done with it.

Usage considerations for sandboxes vs. containers

Determining whether to use a sandbox or container is tricky, and it’s best to use both when possible. Usage will dictate the approach in large part. A typical VM-based sandboxing approach might involve a system picking off suspicious files as they pass the sandbox. This is compelling compared to traditional antivirus, as it does not require an agent to be installed to look for signatures. This, in turn, means that it has the potential to find and correctly flag malware samples that it has no foreknowledge of.

On the other hand, another use case would be using software containers to create a wall around a high-risk application, such as a user’s browser. This approach is usually more endpoint-heavy and relies on configuration of the endpoint and/or application.

To figure out which tool is right for your use case, try to decide which area is currently the largest risk to your environment and determine which one of these options will give you the most protection upfront. Are you looking to supplement your protections against email-borne malware? In this case, a VM-based method integrated into your email gateway might be a good choice. Are you looking to reduce the attack surface for things like drive-by downloads? In that case, a software sandbox might fit the bill.

It’s up to your architecture as to what makes the most sense for your environment, but understanding the difference between containers and sandboxes should definitely provide a starting point.