What is App Sandboxing?

The term “sandbox” originally means a safe environment in which small children can play. In computing, a sandbox makes it possible to isolate and protect system resources and other applications from malware and other threats.

To protect applications from these impacts, developers can wrap their applications with a security policy, or split each application into its own virtual machine. This type of application management improves security by limiting the environments in which certain code can run, and preventing users from accessing environments they do not need access to.

There are major security benefits to sandboxing, and software vendors like Apple and Google are using them to provide users with a secure application environment. Also, another advantage of the sandbox is that it provides secondary security measures to account for human error. It provides another layer of security in case errors lead to unexpected vulnerabilities. Errors are essentially “encapsulated” in the sandbox and isolated from the application, reducing security risks.

App Sandbox Principles

These principles were provided by Apple, for its App Sandbox technology that is part of MacOS (read more in the following section). However they apply to other other sandboxing environments as well.

An application sandbox limits access to sensitive resources on a per-application basis. If an attacker exploits security vulnerabilities in an application, user data could be stolen, corrupted, deleted, or system hardware hijacked for the attacker’s use. A sandbox is a last line of defense, providing protection in case an application is already compromised.

What does an application sandbox limit?

Sandboxes applications should use permissions to clearly indicate their intention to use system resources. This could be anything from files and application data, including downloads, photos, calendar contacts, or the user’s location, to network connections, to hardware peripherals like cameras or printers.

The system denies access to resources not explicitly requested in the application definition at runtime. For example, if you’re writing an application that never needs access to the microphone, don’t ask for access. The operating system will know to reject any requests to access the microphone or any other peripherals not explicitly allowed.

What does an application sandbox allow?

Sandboxed applications should be able to access basic operating system operations that do not carry a large security risk. For example, users should be able to see running services, view files on a read-only basis, and access files specifically created by the user in the application.

Application Sandboxing with Integrated OS Support

There are several operating systems (OS) that provide built-in support for application sandboxing. Below are some notable examples.

Windows Sandbox

Windows Sandbox is a built-in sandbox environment for Microsoft Windows that allows you to safely run applications in a separate, lightweight desktop environment.

When installing software on the Windows Sandbox, the environment isolates it from the underlying operating system. Software components run separately from the host, making other software installed on the host unavailable to the sandbox environment. All software required by the sandbox must be installed directly into the isolated environment.

The sandbox is temporary, so closing it will delete all software, files and state. When you run the sandboxed application again, a new sandbox instance is created.

Related content: read our guide to Windows sandbox.

seccomp-BPF

seccomp-BPF is a sandboxing framework available on Linux. seccomp-BPF, which stands for SECure COMPuting with Berkeley Packet Filters, lets users assign a system call filter to a process.

The filter then allows or disallows access to calls according to predefined parameters. However, you cannot dereference addresses in these parameters, which means seccomp cannot compare strings.

The BPF interpreter used in seccomp was originally designed for network socket filtering, which lets you restrict specific data types coming through a socket. In this process, packets represent system calls and are sent to the BPF interpreter.

The interpreter inspects calls using predefined rules and initiates actions as needed. For example, allowing a call is one type of action and disallowing a call is another. If a call is not allowed, the interpreter can either kill or return the process.

While seccomp was not designed as a complete sandbox solution, it can serve as a tool for creating sandbox environments. seccomp-BPF has been adopted as a component of Android security since 2017.

The Apple Sandbox

Apple offers a sandbox that provides user-level library functions that let you initialize and configure a sandbox environment. Apple’s sandbox does not use BPF technology.

The Apple sandbox comes with a server process dedicated to handling kernel logging, and a kernel extension that enforces sandbox policies via the TrustedBSD API. Another kernel extension provides support for regular expression pattern matching, which is used to enforce predefined policies.

To initialize the sandbox, the system calls the sandbox_init function. The sandbox_init function reads human-friendly policy files and converts them into binaries, which are then passed to the kernel, and the sandbox is created.

Once the sandbox is created, function calls passing through the TrustedBSD layer are moved to the sandbox kernel extension, where the system consults a list of sandbox rules. Actions are then taken according to the predefined rules.

Chromium Native Client (NaCl)

NaCI is a browser plug-in that provides user-level sandboxing capabilities that restrict the type of code a browser can execute and sandbox. It was designed to ensure safe executions of untrusted, platform-independent native code in a browser.

You can use NaCI for a range of applications, including compute-intensive and interactive applications like games. NaCI restricts untrusted code and runs trusted code, letting you run code in a controlled and monitored environment.

To run untrusted code, you need to compile it with either the NaCl SDK or another compiler. Note that the compiler needs to adhere to the data alignment rules and instruction restrictions supported by NaCI.

NaCI does not allow applications to directly access resources. Instead, the code is linked with NaCI libraries, which can provide access to required system services. NaCl comes with a GNU-based toolchain, which contains custom versions of common libraries like gcc and gdb.

Security Pros and Cons of Application Sandboxing

Let’s review some of the advantages and disadvantages of application sandboxing as a security technique.

The Attacker Perspective

Sandboxing an application is highly effective at protecting that specific application from attackers. However, there are many other ways to break into an endpoint:

A user device runs many different applications and an operating system, all of which may have security vulnerabilities, or may be exposed to new zero day vulnerabilities. It is difficult to sandbox all applications on the device.

• Devices often connect to non-secured networks.
• Removable hardware devices such as USB disks can infect a device with malware.
• As long as users have access to email or file sharing services, it is possible for attackers to trick them into running malware on the local device.

For these reasons, sandboxing is one defensive measure, but cannot prevent many types of attacks on the endpoint device.

The User Perspective

On corporate devices, users can leverage application sandboxing to reduce restrictions on the types of files they can access. However, sandboxing has significant downsides for users:

Each instance of the application runs in a separate VM or other containerized solution, which increases performance overhead and slows down the user’s device

• For many enterprise applications, running them in VMs or containers can cause compatibility issues. Many applications are built to interact with a full operating system or other applications, and will not function properly in an isolated environment.
• Even if applications are customized to run in an isolated environment, this creates an ongoing maintenance overhead of adapting each new version of the software to a sandbox.

In summary, while sandboxing can improve security and release restrictions on users, they can result in severe performance and functionality issues that outweigh their benefits for users.

Learn more in our blog post: Application Sandboxing: 3 Perspectives to Consider

App Sandboxing with Hysolate

Hysolate can be used as a sandbox for isolating risky websites, applications documents or ever peripherals. Developers or researchers can download open source-code repositories, access training videos over YouTube, or try out potentially malicious software within an isolated OS, without exposing risk to corporate data.

Hysolate is a full OS isolation solution, splitting your endpoint into a more secure corporate zone and a less secure zone for daily tasks. This means that one OS can be reserved for corporate access, with strict networking and security policies, and the other can be a more open zone for accessing untrusted websites and applications.

Hysolate has several advantages over traditional sandbox solutions. It sits on the user endpoint so provides a better UX, but is managed by a granular management console via the cloud. This means that admins can monitor and control exactly what their team is using the sandbox environment for, and can easily be wiped if threats are detected. Hysolate is easy to deploy, and can be scaled to your entire team, not just the technical members. Hysolate sandboxes applications, websites, documents and peripherals, gives you better security, and manageability.

Try out Hysolate Free today for easier sandboxing to isolate risky activities.