Generates sandboxes for C/C++ libraries automatically
Go to file
Sandboxed API Team 726b1fb451 n/a
PiperOrigin-RevId: 244836017
Change-Id: I034cfb1af4835256aa9b8b7ac3e80a341e9a9271
2019-04-23 05:14:22 -07:00
sandboxed_api n/a 2019-04-23 05:14:22 -07:00
.clang-format Sandboxed API OSS release. 2019-03-18 19:00:48 +01:00
.gitignore Add basic .gitignore file 2019-03-26 04:51:40 -07:00
CONTRIBUTING.md Sandboxed API OSS release. 2019-03-18 19:00:48 +01:00
LICENSE Sandboxed API OSS release. 2019-03-18 19:00:48 +01:00
README.md Merge pull request #12 from PoignardAzur:patch-1 2019-03-25 13:11:10 +01:00
WORKSPACE Disable "mini" debug format support in libunwind to avoid additional library dependency 2019-03-20 08:03:08 -07:00

Sandboxed API

Copyright 2019 Google LLC

Sandbox

What is Sandboxed API?

The Sandboxed API project (SAPI) aims to make sandboxing of C/C++ libraries less burdensome: after initial setup of security policies and generation of library interfaces, an almost-identical stub API is generated (using a template-based programming variable hierarchy system), transparently forwarding calls using a custom RPC layer to the real library running inside a sandboxed environment.

Additionally, each SAPI library utilizes a tightly defined security policy, in contrast to the typical sandboxed project, where security policies must cover the total syscall/resource footprint of all utilized libraries.

Intended audience

SAPI is designed to help you sandbox only a part of binary. That is, a library or some other code with an unknown security posture.

See Sandboxing Code to make sure this is the type of sandboxing you are looking for.

How does it work?

Navigate to our How it works page.

Motivation

Sandboxes available for use in Google required additional implementation work with each new instance of project which was intended to be sandboxed, even if it reused the same software library. Sandbox security policies and other restrictions applied to the sandboxed process had to be reimplemented each time, and data exchange mechanisms between trusted and untrusted parts of the code had to be designed from the scratch.

While designing the Sandboxed API project, our goal was to make this process easy and straightforward. Our working motto is: Sandbox once, use anywhere.

Is it proven technology?

The project has been designed, developed and is maintained by members of the Google Sandbox Team. It also uses our field-tested Sandbox 2.

Currently, many internal projects are already using SAPI to isolate their production workloads. You can read more about them in the Examples section.

We've also prepared some more example SAPI implementations for your reference.

Quick Start

Install the required dependencies, this assumes you are running Debian 10 "Buster":

echo "deb http://storage.googleapis.com/bazel-apt stable jdk1.8" | \
  sudo tee /etc/apt/sources.list.d/bazel.list
wget -qO - https://bazel.build/bazel-release.pub.gpg | sudo apt-key add -
sudo apt-get update
sudo apt-get install -qy python-typing python-clang-7 libclang-7-dev
sudo apt-get install -qy build-essential linux-libc-dev bazel

Clone and run the build:

git clone https://github.com/google/sandboxed-api && cd sandboxed-api
bazel build ...

Try out one of the examples:

bazel run //sandboxed_api/examples/stringop:main_stringop

There are also a more detailed instructions that should help you getting started with SAPI.

Getting Involved

If you want to contribute, please read CONTRIBUTING.md and send us pull requests. You can also report bugs or file feature requests.

If you'd like to talk to the developers or get notified about major product updates, you may want to subscribe to our mailing list or sign up with this link.