Generates sandboxes for C/C++ libraries automatically
Go to file
Christian Blichmann befdb09597 Link more complex test cases dynamically
Linking glibc in fully static mode is mostly unsupported. While such binaries
can easily be produced, conflicting symbols will often make them crash at
runtime. This happens because glibc will always (try to) load some dynamically
linked libraries, even when statically linked. This includes things like the
resolver, unicode/locale handling and others.

Internally at Google, this is not a concern due to the way glibc is being built
there. But in order to make all of our tests run in the open-source version of
this code, we need to change strategy a bit.

As a rule of thumb, glibc can safely be linked statically if a program is
resonably simple and does not use any networking of locale dependent
facilities. Calling syscalls directly instead of the corresponding libc
wrappers works as well, of course.

This change adjusts linker flags and sandbox policies to be more compatible
with regular Linux distributions.

Tested:
- `ctest -R '[A-Z].*'` (all SAPI/Sandbox2 tests)
PiperOrigin-RevId: 429025901
Change-Id: I46b677d9eb61080a8fe868002a34a77de287bf2d
2022-02-16 05:59:13 -08:00
.bazelci Update BazelCI configuration to use Debian 10 2019-10-23 06:10:05 -07:00
.github/workflows CI: Run tests in VM based builders 2022-02-14 05:57:19 -08:00
cmake CMake: Force inclusion of exported functions in add_sapi_library() 2022-02-07 07:23:34 -08:00
contrib Merge pull request #110 from oshogbo:zopfli_fd 2022-02-16 04:56:18 -08:00
oss-internship-2020 Migrate the pffft sandbox to contrib/ 2022-02-09 05:20:29 -08:00
sandboxed_api Link more complex test cases dynamically 2022-02-16 05:59:13 -08:00
.bazelignore Build fixes for recent Bazel versions 2020-09-25 07:25:31 -07:00
.bazelrc Remove Bazel workaround for fully_static_link 2022-01-05 01:51:05 -08:00
.clang-format Update .clang-format to prefer & and * to be close to the type 2020-09-18 02:22:43 -07:00
.gitignore Make CMake superbuild behave more similar to FetchContent 2021-02-03 18:15:15 +01:00
.gitmodules Remove pffft submodule entry 2022-02-10 01:41:12 -08:00
CMakeLists.txt Link more complex test cases dynamically 2022-02-16 05:59:13 -08:00
CONTRIBUTING.md Sandboxed API OSS release. 2019-03-18 19:00:48 +01:00
LICENSE Change license link to HTTPS URL 2022-01-28 01:39:09 -08:00
README.md Update README.md with current year 2022-01-31 07:54:57 -08:00
WORKSPACE Change license link to HTTPS URL 2022-01-28 01:39:09 -08:00

Sandbox

Copyright 2019-2022 Google LLC

Bazel build status CMake build status

What is Sandboxed API?

The Sandboxed API project (SAPI) makes sandboxing of C/C++ libraries less burdensome: after initial setup of security policies and generation of library interfaces, a stub API is generated, 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 its libraries.

Documentation

Developer documentation is available on the Google Developers site for Sandboxed API.

There is also a Getting Started guide.

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.