A Guide To Sandboxing
It may sound like something kids would do at the beach, but sandboxing is a very mature solution to the growing risk of viruses and malware. In essence, it separates individual applications from other programs and system resources, isolating them from wider infection. But how does it work, and why is this technique beneficial?
Head in the sand
A sandbox is a self-contained runtime environment for programs or applications, providing a suitable amount of storage space and memory – and nothing more. It can’t be accessed by other programs, and its own files and folders are unable to replicate or reach external locations. Because boxed contents are unable to affect anything out of their environment, sandboxing has evolved into a key tool against malware and viruses. Virtual machines are a classic example of this principle in action since the operating system doesn’t have direct access to external resources.
This software management strategy is typically employed in one of two ways:
#1. A program or application is inserted into a sealed environment.
Because its contents prevent intrusion or infection from external factors, they are stable and secure – immune to wider infection or incompatibility with other software. That’s useful for key functions like operating systems, or applications requiring high levels of security.
#2. A potentially malicious file is dropped into a sandbox and opened.
If security issues or runtime errors are detected, the contained environment will prevent any harm coming to the device or critical resources. And if the software turns out to be benign, it’ll be forwarded to its original destination. In this scenario, sandboxes are only active temporarily while a new app or file is checked for suspect behavior.
Although sandboxing can take place on any operating system, it’s been enthusiastically embraced by Apple. OS X has supported it for seven years, and Apple’s App Store has demanded each app be sandboxed since 2012. Indeed, it’s a key reason why iOS is less prone to corruption or malware than Android. Microsoft supports sandboxed programs and utilities for Windows users, and Linux actively encourages it with a Secure Computing Mode sandbox pre-installed in its kernel. Sandboxing is also compatible with HTML5, Java and many other programs, frameworks or languages.
A sandboxed object is not, however, completely restricted. It may be able to read or write to other files if permission is explicitly granted by a user, preventing malicious software from determining its own behavior. Rule-based executions identify which processes are permitted, and what level of access is available to areas like registry security. IT firms regularly examine malware in sandboxed environments, to study the software’s behavior in a sealed environment where it can’t do any damage.
Nonetheless, a sandbox might not be appropriate in every scenario. Command line inputs could be unavailable, while backup programs often lack the appropriate permissions to function optimally. As malware evolves, it’s becoming worryingly adept at avoiding sandbox scans. Its ability to initially evade detection by appearing benign (before discharging its payload elsewhere) has led to an evolution in sandbox techniques known as containerization.
Container fright
Containers evolve the concept by placing a program in a permanently isolated environment. Any threat is trapped in a sealed space, unable to relay messages or perform intended functions. This makes containers a better long-term solution for testing incoming programs or applications; detection isn’t necessary when an attack vector is permanently shielded against its intended target. Containers can sit within a software package or on top of the operating system, only accessible via a closely-monitored bridge.