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
This causes whole repo (with history) to be fetched.
Protobuf repo is especially big (>200MiB).
PiperOrigin-RevId: 549285765
Change-Id: Ifb5e3a549a014adb51e6e5eef41e72abf0149558
This is to facilitate online/offline core counting for an accurate count of the
maximum CPU ID that may be seen.
PiperOrigin-RevId: 548715133
Change-Id: I159c0d51b9800fa633172986ba4f8eca352ae336
If a sandboxing target sets a `compatible_with` constraint, the current sapi.bzl doesn't propagate this to the subsequent target generations.
We implement the forwarding similarly to the `visibility` attribute.
PiperOrigin-RevId: 546838438
Change-Id: I8a0b2623ee3aa91ffe7e6f4b001177c03806f532
- If --sandbox2_danger_danger_permit_all_and_log is set, we write to a logfile (passed via the flag).
- If --sandbox2_danger_danger_permit_all is set, we do not write any log information.
This change introduces a means to also see the syscall information on stderr by passing --v=1 and --alsologtostderr.
PiperOrigin-RevId: 542232271
Change-Id: Ie4d30f0d8e25bb1de7c60bb37736b27b89406336
To avoid code that is being parsed to include the intrinsics headers, undefine
a few key preprocessor defines.
PiperOrigin-RevId: 539878995
Change-Id: I8afb7cbdadcab3214c943c0acb9006e8bcc30611
- Abseil
- Protobuf
- Benchmark
- Googletest
In turn, some code changes were necessary:
- Use absolute imports in `sapi_generator.py` when invoked by Bazel
- Add Abseil's source dir as include dir in generated proto `.cc` files
- Bazel: Use `@rules_proto` for `proto_library` and use native `cc_proto_library`
Drive-by:
- Update year in `README.md`
- Look for clang versions 16, 15, 14, and 13 as well in `code.py`
PiperOrigin-RevId: 539032012
Change-Id: Ib9cd1d7fb38409d884eb45e1fa08927f6af83a21
This should only affect the Bazel `BUILD.bazel` files and their formatting.
PiperOrigin-RevId: 538426054
Change-Id: I0162726d3fb4bcb4d7938cddc6f39e0d9f2b4a3d
Also make sure we don't kill everything (with a `kill(-1, SIGKILL)`) if reading the pid fails.
PiperOrigin-RevId: 536371566
Change-Id: I17f6ae36b73ec43735709ff16d276abaebb00d44
To fix Python related errors, explicitly install `libclang1-dev` and `clang`
PIP packages that match.
PiperOrigin-RevId: 532411402
Change-Id: I448a5db4e7d802b7929d93844827906f4e4413de
Drive-by:
- Add flags to link libgcc and libstdc++ statically into the binary, making it
"mostly static"
PiperOrigin-RevId: 532349354
Change-Id: I0a86eb29b6a40aec4cec3cffeaf9511726ee4dc8
Set `SAPI_CLANG_TOOL_EXECUTABLE` to specify the location of a pre-built Clang
tool based header generator.
PiperOrigin-RevId: 531425738
Change-Id: I723d19122cc738d9906c8c568d156d44c58d9746
Tested on Debian 10.13 with `LLVM-{11,12,13,14,15,16,17}` packages from https://apt.llvm.org/.
PiperOrigin-RevId: 531211601
Change-Id: I91babb5d85be2a22a4b17d757a5f626de6c03881
CMake already provides `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES`, so there's
no need to invoke the compiler to determine system include directories.
For the Clang tool based header generator, adding the includes from the
current toolchain is strictly more correct than having it try and figure them
out itself (which will favor files from any installed libc++ and/or Clang).
PiperOrigin-RevId: 531207747
Change-Id: Icfcf7b495a0a5782c21a665984d9039d365db898
`SAPI_ENABLE_GENERATOR` => `SAPI_ENABLE_CLANG_TOOL`
This prepares further changes in this area.
PiperOrigin-RevId: 531201213
Change-Id: I56bd450e6ed2dd1dbbf45db2825a75c56d277037
This avoids a warning in newer CMake versions. For `CMP0083`, we still need to
explicitly select `NEW` behavior. `check_pie_supported()` will error if it is
unset even on later CMake versions.
PiperOrigin-RevId: 531200735
Change-Id: Icb17a00cac087bd6888f8a9b9f8dd837358a6090
This makes should ensure global forkserver will be single threaded before forking the sandboxees as it does not go through WaitAndFork.
Waiting for sanitizers is not needed in the monitor and should reduce latency
by 1 second for all sanitizer builds. Currently it'll always wait up to 1 seconds for the process to become single-threaded, which will never happen as monitor itself is running in a separate thread.
PiperOrigin-RevId: 530878018
Change-Id: Ie9f663848502f2738721861b0ba2dc6f3cc9f1c9
