| commit | 04ed89906b48175e02cc9faf6d52b05278ec367b | [log] [tgz] |
|---|---|---|
| author | Oliver Kunz <okunz@google.com> | Tue Jul 25 04:37:13 2023 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Tue Jul 25 04:38:43 2023 -0700 |
| tree | 649eb9bc3b0bdcba8b2b697f831d42fd254c3ddc | |
| parent | 9d1d4b7fd38270e825bdc1cda80cbda51ed46d17 [diff] |
Adding AllowOpen to AllowLlvmSanitizers to avoid having to add AllowOpen in addition when it's only needed for running under the sanitizers. In cases where SAPI users overwrite the default policy instead of extending it, the sandbox will fail with an `openat` violation. This is automatically inherited in the default policy. The advantage with this implementation is that we don't expose the open* syscalls when not running under the sanitizers. PiperOrigin-RevId: 550845188 Change-Id: I151d467848983b00b71ec8447d662394fa7176db
Copyright 2019-2023 Google LLC
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.
Developer documentation is available on the Google Developers site for Sandboxed API.
There is also a Getting Started guide.
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.