application sandboxing

What is application sandboxing?

Application sandboxing, also called application containerization, is an approach to software development and management and mobile application management (MAM) that limits the environments in which certain code can execute.

The term sandbox comes from the idea of a child's sandbox, in which the sand and toys are kept inside a small container or walled area so children can play safely.

With the sandboxing approach, every software application is given a "sandbox," which is a controlled, restricted environment to run and execute code. This environment helps developers isolate and protect system resources from malware and other kinds of cyberthreats.

Researchers also use sandboxes to identify how a software behaves and spot any malware or other undesirable program elements.

The aim of application sandboxing

Application sandboxing seeks to improve security by isolating and shielding the application from outside intruders or malware. It's also used when preventing system resources or other applications from interacting with the protected app is necessary.

This kind of separation helps create a secure environment so the app can run without the risk of damaging the overall system. The approach is especially useful to run or test applications from untrustworthy sources (e.g., unknown developers) or websites.

Sandboxing also increases application integrity; it lets developers wrap the app in security policies or isolate and protect the application within its own virtual machine. The latter approach is known as micro-virtualization.

Application sandboxing benefits

The primary benefit of application sandboxing is enhanced security. By limiting the environment in which codes can execute, developers protect the app from outside influences, whether these are system resources or nonmalicious bugs, or malicious malware or hackers.

Application sandboxing is also beneficial because of the following:

• ensures a secure application experience for users;
• prevents users from accessing environments they do not need access to or should not access;
• provides additional security in case of errors caused by unexpected bugs or vulnerabilities; and
• encapsulates and isolates even human errors within the sandbox so the outside environment is intact.

Major software vendors like Apple and Google count on these benefits of sandboxes to provide secure application environments to users.

Types of application sandboxes

Some of the most common types of application sandboxes include:

• User-level validation
• OS support
• Browser-based
• Java sandbox

Application sandboxes with user-level validation

Here, interaction between an application and its environment happens via system calls to the operating system (OS). This includes interactions like accessing devices or files, changing permissions, accessing the network, etc. The sandbox lets users create policies defining permissible system calls and how they can be used. It will review every system call, check its parameters and decide whether to allow it or return an error.

A crucial drawback of user-level validation is possible time-of-check-to-time-of-use (TOCTTOU) race conditions. By the time the request is processed and the system call is validated, the environment may change.

Android sandbox

The Android platform isolates apps from each other and protects them -- and the overall system -- from malicious apps and intruders. Android assigns a unique user ID (UID) to each application to create a kernel-level sandbox. This kernel ensures security between apps and the system at the process level. Moreover, because the sandbox is in the kernel, its security model extends to native code and OS applications, and all software above the kernel, including OS libraries, application runtime and application framework.

To identify and isolate app resources, the Android sandbox offers Linux user-based protection through standard Linux facilities such as user and group IDs assigned to apps. Apps cannot take malicious action against other apps in the sandbox because they don't have the appropriate default user privileges required to do so. The sandbox is auditable and it's based on the Unix ideas of process separation and file permissions.

Application sandboxing with integrated OS support

Consider some examples where the OS provides a built-in kernel support environment for application sandboxing:

Windows sandbox

Windows sandbox gives users a safe, lightweight environment to execute code and run applications. The environment is also temporary because all files, state and software are deleted once the sandbox is closed. Running the sandbox application again creates a new sandbox.

Notably, with the Windows sandbox, software components inside the environment run separately from the host, isolating the application from the underlying OS. All other software installed on the host are unavailable to the sandbox environment, and all applications that need the sandbox environment must be installed directly in the isolated environment.

Linux sandbox -- seccomp-BPF

SECure COMPuting with Berkeley Packet Filter (seccomp-BPF) is a sandboxing framework for Linux systems. Seccomp uses the BPF interpreter that lets users create filters to restrict specific data types to come through the socket. Users can assign a system call filter to a process, which then lets them allow or disallow access to calls based on predefined parameters.

Apple sandbox

Apple also provides a kernel-level sandbox with user-level library functions. However, it does not adopt the BPF filter, like the Linux sandbox. The Apple sandbox includes a server-level process to handle logging from the kernel, and a kernel extension to enforce sandbox policies via the TrustedBSD application program interface (API). Initially, an application calls the sandbox by calling sandbox_init that reads the policy definition file and converts it into a binary format for the kernel that initializes the sandbox.

Browser-based application and sandboxing

Web browsers can support a plugin architecture for application sandboxing. Modules that contain the native code can be loaded into the browser. This enables download of the requested content and invocation of the plugin associated with the object type invoked on the content. Common plugins include Adobe Flash, Adobe Reader, Java, etc.

Chromium Native Client (NaCl) is an example of sandboxing that specifically addresses the risk of running untrusted native code in a plugin and web browser. Chromium is the Open Source project behind the Google Chrome browser and NaCl is the browser plugin designed to safely execute untrusted native code in a browser.

NaCl, a user-level sandbox, executes with an inner sandbox and outer sandbox. The inner sandbox uses Intel's IA-32 architecture's segmentation capabilities to isolate memory regions among apps. The outer sandbox restricts app capabilities at the system call level.

NaCl also supports two categories of code: trusted and untrusted. Trusted code can run without a sandbox. Untrusted code must run inside a sandbox.

The Java sandbox

The Java sandbox is also known as the Java Virtual Machine (JVM), a hypothetical architecture where the application author does not know the client's OS or hardware architecture.

The three main components of a Java sandbox are:

1. The bytecode verifier
2. The class loader
3. The security manager

The bytecode verifier ensures that the code looks like a Java byte code without any attempts to illegally convert data, bypass array bounds or forge pointers.

The class loader is responsible for enforcing restrictions on whether a program is allowed to load additional classes. It implements address space layout randomization (ASLR) while ensuring that key parts of the runtime environment are not overwritten and there's no interference of malicious code with trusted code. The security creates the protection domain. It creates the sandbox boundaries and is consulted for access to any resources. It throws a security exception error when any actions not allowed or defined in the policy are invoked.

See also: Build a virtualized development environment with these guidelines and learn about the first sandboxed antivirus: Windows Defender.