Sandboxing Library for Python
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-chroot to be installed and setuid root
Possible future backends
Relationship to other projects
libsandbox / pysandbox
The libsandbox library is a Linux-specific implementation of process sandboxing, which supports intercepting syscalls, calling setrlimit(), and dropping certain privileges.
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).
xdg-app (GNOME Application Sandboxing)
The xdg-app 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.
xdg-app 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.
App Container spec
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.
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.
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:
However, other Python runtimes do support language-level sandboxing. PyPy is one:
The YBD build tool (from Baserock) triggered the creation of the ‘sandboxlib’ library.
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.