This project is a total work in progress, no documentation yet.
It is being developed as part of the Baserock project.
The goal of this library is to provide the sandboxing functionality that is already present in the build tools Morph and YBD. We want this new library to be usable without depending on linux-user-chroot, so that it can be used on Mac OS X, and hopefully other platforms too.
A longer term goal is to become a useful, generic, cross-platform tool for running commands in an environment that is partially isolated from the host system in some way.
The library is implemented in Python currently. This is mostly because it is an adaptation of existing Python code, not because of any desire to exclude other languages. Maybe we could rewrite it as a C library with Python bindings.
SANDBOXLIB DOES NOT GUARANTEE YOU ANY KIND OF SECURITY. Its main purpose is for isolating software builds from the host system, to ensure that builds are not contacting the network, or reading or writing files outside the build environment.
- chroot: any POSIX OS, requires 'root' priviliges
- linux-user-chroot: Linux-only, does not require 'root', requires
linux-user-chrootto be installed and setuid root - bubblewrap: Does not require 'root', requires
bwrapto be installed.
- Firejail
- runC
- Security Enhanced Linux (SELinux): see https://danwalsh.livejournal.com/28545.html
- systemd-nspawn
- Warden
Fakeroot and the comparable tool Psuedo_ operate by using LD_PRELOAD to intercept filesystem operations from processes. If any of these processes require special privileges, it "fakes" the operation by recording it in a database, and rewriting query responses so that the operation appears to have taken place. They are widely used in operating system build tools.
The libsandbox library is a Linux-specific implementation of process sandboxing, which supports intercepting syscalls, calling setrlimit(), and dropping certain privileges.
MBox implements sandboxing using LD_PRELOAD, in a similar way to Fakeroot.
Minijail: Process sandboxing implemented using an LD_PRELOAD library that sets up seccomp profiles. Developed by Google and used in Chrome OS & Android. See also: the LWN writeup on Minijail.
The PRoot tool provids features similar to linux-user-chroot, plus some extra code to allow running programs for a different architecture using virtualisation. The PRoot tool is discontinued.
Sandstorm.io aims to be a platform for running web applications on shared infrastructure, with individual users in mind.
It uses the 'namespaces' feature of Linux. See https://github.com/sandstorm-io/sandstorm for more information.
Sandstorm.io is for a specific use case of web application sandboxing, so it doesn't make sense for sandboxlib to wrap it. Use it directly if it suits your purpose!
The Linux kernel provides the seccomp syscall, which can be used in two ways.
The SECCOMP_SET_MODE_STRICT operation creates a very restrictive but secure
sandbox. Most programs wouldn't work in this sandbox, but it does have some uses.
It is used by Google Chrome,
among other things.
The SECCOMP_SET_MODE_FILTER operation allows blacklisting certain system
calls. This can be done in such a way that most existing programs work, but
certain obvious security holes in a sandbox are closed (for example, the
kexec() system call).
The flatpak project started from a desire in the GNOME desktop project to allow running 3rd-party applications with some isolation from the host system. Mobile platforms like Android and iOS have been doing this for some time already.
It implements sandboxing mainly using the 'namespaces' feature of Linux. Find out more about the project.
flatpak is for a specific use case of desktop application sandboxing, so it doesn't make sense for sandboxlib to wrap it. Use it directly if it suits your purpose!
There is a lot of overlap between the topics of 'containerisation' and 'sandboxing'. Many tools that work with 'containers' expect that containers are long-lived things, where the 'sandboxlib' library treats a sandbox as a much more lightweight, temporary thing.
I have been using the App Container spec as a reference during development.
The scope of 'sandboxlib' is different to that of the App Container spec:
'sandboxlib' only deals with a single, isolated sandbox (which may or may
not be a 'container'), where the App Container spec is focused on multiple
containers. However, 'sandboxlib' would be a useful building block for
implementing a complete App Container runtime, and simple App Container images
(.acis) should be runnable with the run-sandbox tool directly.
Intel are producing a Linux distribution named Clear Linux, as part of a project to develop what they call Clear Containers. The idea is to make virtualisation with QEMU fast enough and convenient enough to compete with current containerisation software. All current containerisation systems use kernel namespacing, which provide a much weaker security barrier than full virtualisation.
The implementation depends on Linux's KVM feature, plus patched versions of QEMU and Linux.
Docker allows managing multiple prebuilt container systems. While it can support multiple platform-specific backends for running containers, I am only aware of Linux-specific backends at the time of writing.
Garden is an abstraction layer with multiple backends for container creation and management. It appears to have a much heavier footprint than 'sandboxlib', it is perhaps useful if you want an equivalent of 'sandboxlib' but for long-running containers that require ongoing management.
Garden's existing Linux backend is based on code from Warden, but there is ongoing work to use runc instead.
The Open Container Specification is an effort to standardise containers. It was started more recently than the App Container spec and may or may not supercede it.
runC is a runtime for these containers. It is based on code from Docker.
PySpaces is a pure Python container implementation, which uses Linux namespaces.
The use case for the schroot tool is 'I want to define a contained environment once, and use it many times.' The 'sandboxlib' library is more about dynamically creating sandboxes. If schroot suits your needs, just use it directly without any abstraction layer.
A tool with similar purpose to linux-user-chroot, but some different tradeoffs.
Warden is another Linux container runtime, developed by the Cloud Foundry project. It has a client/server architecture allowing multiple implementations of sandboxing to be mixed. Currently it has two backends: 'linux' and 'insecure'.
The 'sandboxlib' library is for sandboxing any program, at the operating system level.
If you want to do language-level sandboxing (i.e. run untrusted Python code within a larger Python program), there are some ways to do it.
The concensus seems to be that Python language-level sandboxing is pretty much impossible with the default 'cpython' Python runtime:
- https://mail.python.org/pipermail/python-dev/2013-November/130132.html
- https://programmers.stackexchange.com/questions/191623/best-practices-for-execution-of-untrusted-code
However, other Python runtimes do support language-level sandboxing. PyPy is one:
The Bazel build tool contains a Linux-specific sandbox implementation.
The Morph build tool (from Baserock) is the original source of the 'sandboxlib' linux_user_chroot backend. Hopefully Morph will adopt the 'sandboxlib' library in future.
The YBD build tool (from Baserock) triggered the creation of the 'sandboxlib' library.
- Awesome Linux Containers
- Sandboxing for multi-tenant applications (archived)
- StackOverflow question "Run an untrusted C program in a sandbox in Linux that prevents it from opening files, forking, etc.?
- StackOverflow question "How to "jail" a process without being root?
License is GPLv2 but other licensing can be considered on request
Most of the copyright is currently Codethink but don't let that put you off. There's no intent to keep this as a Codethink-only project, nor will there be any attempt to get folks to sign a contributor agreement. Contributors retain their own copyright.