First, a bit of history: Back when computers were first made they could only run a single program, and that program had full access to all the hardware that made up the computer. Once computers started getting more powerful, researchers realised that having a lot of programs running at the same time was a good way to save money, perhaps even allow computers to run programs from different users. Operating systems such as Unix were made to do this in a reasonably secure way, where software running as ordinary users (in “user-space”) had limited access to system resources, as opposed to software running as the “root” user.

Eventually we get to today, where smartphones are so powerful that they are comparable to supercomputers from the late 1990s. All this power makes it possible to use software to protect the user in ways that were not possible before. Virtualisation, containers and sandboxes are new ways of using computers both more efficiently and securely.

Virtualisation is the most generic term of the three that we’re discussing. In the most simple way, it means making a virtual version of something physical. This can be a virtual computer hardware platform, virtual storage, or virtual network resources. Both containers and sandboxes can thus be examples of virtualisation. Today, the most common usage for the term virtualisation is when talking about environments where the physical hardware has been virtualised. 

When using virtualisation you would - in most cases - use a complete copy of the same software as you would otherwise run on real hardware, the only difference is that you do not have physical access to the hardware. Systems such as hyper-v or VMware are popular platforms that use virtualisation.

Containerisation is a more recent application of virtualisation and is also known as “operating-system-level virtualisation”. With containers, the underlying hardware is not virtualised, but instead, the operating system makes isolated “user-space” environments. An application that runs within such a container will believe that it is the only application running. 

From a security perspective, the fact that applications cannot see each other is a major perk. An added benefit to this is that the attached surface of the application is smaller than if it was not running within a container. Software such as Docker uses this kind of virtualisation. As the containers share the underlying “kernel” this can be a very efficient way of protecting untrusted applications from each other.

One well-known example of containers in the mobile space is Samsung’s Knox Container, that lets you have a second instance of Android on your phone, protected from your normal environment.

Perhaps the most complicated term we discuss here are sandboxes, as it is used in a few different contexts. Today, one of the most common uses for the word sandbox might not even be directly related to computer security. When a vendor invites you to run your software “in their sandbox” they might not mean a secure environment where you can run your software, but rather just an API you can connect to from your own server. In this context, a sandbox is more like a play area for kids.

In computer security, a sandbox can refer to at least two related technical mechanisms: When talking about operating systems, a sandbox is an environment you run applications in so that the application is restricted from getting full access to other applications. When it comes to iOS and Android, they each have slightly different forms of sandboxes but essentially work in the same manner: Each app has a list of the resources that it wants to access, which the users have to approve, either when installing the app or when the resource is needed. For hackers, the OS sandbox mechanism is a tempting target. If their malware can escape the sandbox, there is no real limit to what the malware can do. 

The second, perhaps more traditional way, that the term sandbox is used is as an environment where software can run so that it can be analysed for security issues. This is done by monitoring what the application being analysed is doing so that any potential security issues can be discovered before it is allowed to run in a production environment.

In article 22 of the European Commission’s “Regulatory technical standards for strong customer authentication and command and secure open standards of communication” (RTS) there is a general requirement that “Payment service providers shall ensure that the processing and routing of personalised security credentials and of the authentication codes generated in accordance with Chapter II take place in secure environments in accordance with strong and widely recognised industry standards.”

This requirement of using a secure environment would also be valid for the smartphones where end-users might enter their credentials to access their banking app. The obvious question that follows from this requirement is “when is a secure environment secure enough” if it runs on a customer’s device? From a computer security researcher perspective, the only truly secure environment is one which is turned off, and located in a safe on the bottom of the ocean.

With Okay, we’ve tried to do a more practical approach where we create a secure environment in software, running on your device. You can read more about that on our product pages.

Love the topic of containers, virtualisation, and sandboxes? Check out this new blog post where we take an even deeper look on how they have provided sound isolation on computing devices.