Mini-sandbox: an incremental general-purpose solution to sandbox applications
Sign up for Developer monthly newsletter
Join thousands of developers around the globe who receive latest news and updates from our monthly curated newsletter.
Sign up
Come for support, stay for the community
Get support from experts, connect with like-minded developers, and access exclusive virtual events.
Join Developer DiscordTL;DR
Alessandro and Raffaele, engineers in the Product Security team, introduce a new solution named “mini-sandbox” whose goal is to sandbox untrusted code – lighter than full blown containers, easy to embed in your existing code base and practices and completely root-less. PRs and feedback are more than welcome at the mini-sandbox GitHub repo.
It’s 5PM on a Friday and in the last attempt to make your build pipeline work you have just downloaded dozens of completely unknown packages.
Yes, thousands of lines of code authored by someone else are now ready to run on your machine and can potentially access your data and resources. No worries!
Alessandro and Raffaele, engineers in the Qualcomm Product Security Initiative, are working on a new open-source project and are eager to share it with a broader community.
The project, still under development, is named “mini-sandbox” and consists of a scriptable and granular solution to run untrusted code in a secure and isolated environment, a.k.a. a sandbox.
Before taking a deep dive into mini-sandbox, it is worth noting that the key aspect behind this effort is to make it easy for developers to adopt.
While reviewing other alternatives in the scope of sandboxing and containment strategies we realized one thing – there are some valid solutions out there and they do a great job from many perspectives, but they all require a major overhead to deploy sandboxing into a certain codebase and cannot be easily employed as a “drop-in” solution.
On the other hand, mini-sandbox focuses on ease-of-use principles and tries to simplify the life of developers and users without requiring system-level configurations, privileged commands or heavy changes to the codebase. This is why we decided to work on this project - scroll down to see an informal comparison at the end of the article.
As mini-sandbox is in its infancy compared to some of the other available solutions, we are not proposing it as a replacement for them. Nevertheless, we felt like we were at a point where the community might have benefited from it, and we could have gathered feedback about some future directions.
If you believe this is interesting for you give it a try at https://github.com/qualcomm/mini-sandbox. We welcome PRs, any type of discussion, and would love to hear from you.
Sandboxing 101
Sandboxing is a wide-spread technique to isolate and compartmentalize untrusted software. This technology offers the ground to mitigate one of the most debated and unresolved problems of the software development industry, supply chain security.
The idea is to run each application/process in a different sandbox, without affecting the rest of the system. The sandbox constrains the untrusted software to perform only certain actions, reducing the level of trust given to code authored by 3rd parties.
This approach provides a potential mitigation to the impact of a supply chain attack: in case the running application is compromised, if operated and configured appropriately the only affected system is its own sandbox, and the host system is kept safe because it is protected by a security boundary.
During recent years, this idea has been taking ground, and multiple sandboxing technologies emerged with different approaches and different granularities. Some at the API level, like Rlbox and sandboxed-api (What is Sandboxed API? | Code Sandboxing | Google for Developers), others at the process level like nsjail, Podman or Docker, with anappropriate configuration, or gVisor.
However, during our day-to-day tasks, we have observed that most of these techniques require the users and developers to heavily modify their code, generate complex profiles for their target application or modify the end-user system.
This requires a decent amount of additional work to run a target application inside a sandboxed environment with the outcome that in many cases sandboxing is not implemented at all.
Mini-sandbox stands out by emphasizing ease-of-use principles and reducing the amount of configuration required by developers and end-users to set up a functional sandbox.
Our goal is to provide a drop-in tool that can sandbox most of the applications without any or minimal configuration.
Getting started
The easier way to obtain mini-sandbox is to download the latest version from the release page, decompress it and start using it with the default command line: “mini-sandbox -- /bin/bash”.
Double check the “Getting started” section in our repo.
Compatibility Notes
We support most flavors of Linux such as Ubuntu, Debian, SUSE and RedHat even though for Ubuntu24.04 you might have to manually disable AppArmor for mini-sandbox to work effectively (starting from kernel 6.8).
More information in the documentation folder of the repository. We do not support Windows and MacOS, like the other projects in this scope.
Bonus features of mini-sandbox
This project is heavily inspired and derived from other sandboxing technologies, yet it attempts to maximize the “deployability” and usability of the project, finding different trade-offs.
In the following table you can see an informal comparison of what features we considered for our evaluation and how other projects correlate to mini-sandbox. For Docker we only include its root-less version as it can run with or without root permissions alike.
Here are a few clarifications about the columns’ names. “Root-less” refers to the ability to run the tool without root access. Notice that even though all the tools do not require root capabilities to run, only two can benefit from a “root-less” firewall, e.g., Podman and our own mini-tapbox.
All other tools will still require root access to configure the firewall, making the deployment very unpractical/unsecure. More details about this in the following subchapters.
The column “Drop-in” indicates if a tool can be used as-is without requiring complex configuration files (e.g., Dockerfile, Containerfile, etc.).
“OverlayFS” refers to the possibility of mounting certain folders as overlayFS, a feature that is not extremely common but gives us an additional level of flexibility as explained in the next section.
Finally, a green flag under “library” means that we can run that tool as a library and invoke it from inside the application that we want to protect. As we will see in the last subchapter, this is a key feature to simplify the adoption of our sandbox.
Under the hood we still leverage user namespaces, a well-known Linux kernel feature used in all the projects in the table as well as chroot to isolate the execution environment of our mini-sandbox.
On top of that, we have implemented the following three features that make our tool more suitable for general-purpose use cases where developers and end users do not want to invest a major amount of time in writing a sandbox profile like a Dockerfile, advanced firewall policies, etc.
Filesystem management
We implement a “greedy” filesystem management approach that relies on a combination of overlay filesystem (inspired from Docker), read-only filesystem and bind mounts.
The goal here is to let the target application read from most of the host filesystem’s locations (except for secrets and similar artifacts) and access most of the dependencies installed inside the host but at the same time, preventing the application from writing/editing existing files, except for the output path.
We accept the compromise of having the “sandboxee” being able to read most of the files in the host machines in return for having a drop-in tool that doesn’t require sophisticated configuration. This is an acceptable use case especially considering that in several scenarios we run the sandbox with no or heavily reduced internet access.
Root-less firewall
Driving inspiration from Podman, we implemented a root-less firewall. The idea is conceptually straightforward: we want to be able to run “iptables” or something similar inside our sandbox and make it work only for processes that run inside it without affecting the rest of the system.
The solution required us to use a TAP device and implement a TCP/IP stack to manage IP packets. For the latter, we rely on the “gVisor” network stack which exposes most of the functionalities we need, and it is implemented in memory-safe language Go.
Once we have access to a “virtual” network interface inside the sandbox we can run iptables-nft/nft or even write our custom logic in the network stack for blocking or allowing IP packets.
This feature allows us to run applications that need access to the internet maintaining all aspects of our sandbox and without having to implement complicated IPC mechanisms.
Library mode (C and Python)
We have added a library mode - meaning we compile our logic as a library (both shared object and static) and let the library fork and run the leftover code inside the sandbox. An additional feature that comes for free is the possibility to create python bindings that use this shared object.
Obviously, the library mode comes with a handy set of APIs that can be invoked from within the target application that we want to sandbox to establish what folders should be writable, what network connections are needed, and few other parameters needed to tune the sandbox.
What works today and known limitations
We believe that mini-sandbox handles extremely well scenarios where you need to execute untrusted user space code “on-the-fly" on your machines and do not want/have access to a root or admin account.
As explained above, while most of the mini-sandbox features have been inspired by other projects, it is hard to find all of them at once.
Keep in mind that mini-sandbox is still an early-stage OSS project and some limitations will likely be addressed in the upcoming future.
Few known limitations are:
- AppArmor in Ubuntu24+ might block the creation of user namespaces. Few solutions exist but need to be tested out. For now, users are requested to configure their machine to let mini-sandbox work (see documentation)
- So far, there is no easy way to start a new process inside an existing instance of mini-sandbox (e.g., In case multiple processes need to communicate with each other and they are not parent-children)
Connect with us
The project is actively maintained, and we look forward to receiving your feedback, whether this is a pull request to implement a new feature or a new issue to improve mini-sandbox. Feel free to reach out to us
Closing Remarks
The new tool mini-sandbox represents a handy solution to address security concerns in different general-purpose scenarios.
Use cases are many and we have to prioritize some of them but we strongly encourage the open-source community to reach out to us and share thoughts or comments.
