- Drop `delim` argument from the `GetStackTrace()` family of functions.
We only ever used plain spaces.
- Use an `std::vector<std::string>` for the symbolized stack frames and
adjust the unwind proto accordingly.
This change now prints each stack frame on its own line while skipping
duplicate ones:
```
I20200717 11:47:16.811381 3636246 monitor.cc:326] Stack trace: [
I20200717 11:47:16.811415 3636246 monitor.cc:337] map:/lib/x86_64-linux-gnu/libc-2.30.so+0xceee7(0x7fb871602ee7)
I20200717 11:47:16.811420 3636246 monitor.cc:337] Rot13File+0x130(0x55ed24615995)
I20200717 11:47:16.811424 3636246 monitor.cc:337] ffi_call_unix64+0x55(0x55ed2461f2dd)
I20200717 11:47:16.811429 3636246 monitor.cc:337] map:[stack]+0x1ec80(0x7ffee4257c80)
I20200717 11:47:16.811455 3636246 monitor.cc:339] (last frame repeated 196 times)
I20200717 11:47:16.811460 3636246 monitor.cc:347] ]
```
PiperOrigin-RevId: 322089140
Change-Id: I05b0de2f4118fed90fe920c06bbd70ea0d1119e2
Initializing `absl::Span`s like by assigning them from a temporary
array leaves them pointing to invalid data. Due to the way the linker
initializes these constant tables, _most_ of them will still be valid
_most_ of the time, leading to crashes when running sandboxees with the
`--sandbox2_danger_danger_permit_all_and_log` option.
PiperOrigin-RevId: 321112099
Change-Id: I891118da08cbb6000b3e2e275618bc4edaa1d020
Otherwise ExecuteProcess is implicitly `[[noreturn]]` and this
might cause policy violations in `__asan_handle_no_return`
for ASAN builds.
PiperOrigin-RevId: 319203128
Change-Id: I5c8ba71ce88261f803aa3f16730eccea0d803dd1
- Extract dependent types directly from the Clang AST and re-serialize
back into compilable code
- Collect types and emit diagnostics
- Format generated code
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
Similar to what the Bazel build does, this change adds zlib as an additional
dependency when `SAPI_ENABLE_EXAMPLES` is set to `ON`.
PiperOrigin-RevId: 309203959
Change-Id: I201a9e6415789afb1e058bc48cebbc0fc0004fe9
BoringSSL (which is the crypto library used by most Google products) is starting to use madvise(_, _, MADV_WIPEONFORK) to protect random-number state from being duplicated by fork(). This causes extra madvise calls that sandboxes need to permit in order to continue functioning.
PiperOrigin-RevId: 309173849
Change-Id: I007dacc1ff1fd0ccc138caaa08735cfe5bc78234
When embedding SAPI in an external CMake project, the version of
`protobuf_generate_cpp` that we lifted from upstream protobuf produces
the wrong generated file paths.
For example, given this project structure:
```
/parent/
+-- myproject/
+-- myproject_build/ <- CMake build directory
+-- sandboxed-api/ <- Checkout from GitHub
```
And a CMake file in `myproject/CMakeLists.txt` that embeds SAPI like
this:
```
cmake_minimum_required(VERSION 3.12)
project(SandboxedTest LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_subdirectory(
${PROJECT_SOURCE_DIR}/../sandboxed-api
${PROJECT_BINARY_DIR}/sandboxed-api
)
```
Then `protobuf_generate_cpp` correctly invokes the protoc compiler to
generate
`/parent/myproject_build/sandboxed-api/sandboxed_api/proto_arg.proto.pb.cc'.
However, the path of the generated source file that is passed to the C++
compiler will be
`/parent/myproject_build/sandboxed-api/sandboxed_api/../../myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
Note the duplicated project build directory component in the
canonicalized version:
`/parent/myproject_build/myproject_build/sandboxed-api/sandboxed_api/proto_arg.pb.cc`.
This change simple omits the computation of any relative file paths and
simply uses `_pb_PROTOC_OUT_DIR` which defauls to
`CMAKE_CURRENT_BINARY_DIR`, which should always contain the correct
path.
Signed-off-by: Christian Blichmann <mail@blichmann.eu>
Created documentation for network proxy. fixed 2 things in documentation (namespaces are enabled by default for a while).
PiperOrigin-RevId: 300321016
Change-Id: Id9c54b29551e8d3b70e814e2fdbfee594126aa90
Sending -1 as fd will fail and take forkserver down.
This should not happen normally so turned it into a check.
PiperOrigin-RevId: 285391908
Change-Id: Idbb05004c36cb0be57be1bd26df1c57cecfb0019
This addresses a latency issue - chroot_fs_refs called inside pivot_root
in the kernel can take several milliseconds on machines with many threads
running.
This might not always reduce latency for custom forkservers, as additional
fork can be more costly than pivot_root.
PiperOrigin-RevId: 281306284
Change-Id: If503ac76a70e5438e94caf708d79cb0219c66def
The previous one was not quite correct in cases where the outside binary path
did not match the inside path. This should be fixed with this.
PiperOrigin-RevId: 276075886
Change-Id: I1c7c4fa0191960437a2d2360b805c7098b1407c9
Caused failures if root is mounted as nodev, nosuid etc.
Root is pivoted and unmounted right after this anyhow.
PiperOrigin-RevId: 273707731
Change-Id: I75f1edaf2877c096e4f5bb7dc1b2bb8eb5c437a3
This makes the class more ergonomic because
* You don't have to heap allocate the builder.
* You can create a policy builder "template" and re-use it across sandboxes to avoid repetitive work.
PiperOrigin-RevId: 273555679
Change-Id: I4084ee9c74f95ebfde873eb0dc021b3b3cdc5ea2
These where inadvertently introduced in an internal cleanup change.
This change also removes a C++17-ism in var_proto.h. To make things easier for
downstream projects, we should stick to C++11 for the time being.
PiperOrigin-RevId: 271117700
Change-Id: I4eaacec88be16e1a561d3f77a61acce0a1af0b9d
This change removes the in-tree documentation in favor of the one hosted on
the Google's Developer site. This makes it easier to maintain for the
sandbox team, as there is now only a single source of truth for both internal
and external documentation.
If you find errors/bugs in the documentation, please file regular GitHub
issues.
PiperOrigin-RevId: 267132623
Change-Id: I4c950fcef77da0b361cb35b99aa2f187efe6f320
The temporary solution for binaries/tests that fully statically linked is to
link against `gflags` using `-Wl,--whole-archive`. This will no longer be
necessary, once Abseil ships with logging. Then we can (finally) use Abseil
flags and use a logging library that does not depend on a different flags
library.
PiperOrigin-RevId: 260705702
Change-Id: I8562faaff59f9c3e0e1d331186d2806d387438fb
This change moves away from a classical superbuild which downloads and builds
at build time. Instead, we now follow a "Fetch Content" workflow (available as
FetchContent in CMake 3.11+) and download dependencies at config time.
Rationale: Superbuild projects have the disadvantage that projects cannot
directly access their individual declared targets. This is not a problem with
regular libraries, as those are usually/supposed to be installed. With
Sandboxed API, this is not desirable, as it has dependencies like Abseil and
glog, which are almost always consumed by including their source tree using
add_subdirectory().
Fixes#10 and makes external embedding easier.
PiperOrigin-RevId: 260129870
Change-Id: I70f295f29a6e4fc8c330512c94b01ef10c017166
Also properly check status of send and use one-byte messages
to avoid issues with partial send, receive.
PiperOrigin-RevId: 258362495
Change-Id: I889b4699c100c80d15b129bf3a254f5442405bc2
PR_SET_PDEATHSIG is already issued for init process in SanitizeCurrentProcess
Same for setsid
PiperOrigin-RevId: 258142844
Change-Id: Iad9e94bd402d576c1b24caab0b03efc50e2df07e
* Move add_sapi_library() into a build defs file
* Override protobuf_generate_cpp() instead of naming it sapi_protobuf_generate_cpp()
* Factor out inclusion/find_package() calls of external dependencies
PiperOrigin-RevId: 258133422
Change-Id: Ibdbab0c735157eac0ed6122ab78f9d583c6905cc
When fetching exit status only lower 8-bits will be read.
Thus if getpid()&0xff == 0 the test can fail.
PiperOrigin-RevId: 257163766
Change-Id: I690c645fde33d1205578fd8873c5fc2974352ada
Since we use glog, we need to still rely on gFlags for as long as Abseil
logging is not yet released. To do this, we have the util/flag.h header in
SAPI, faking the newer style API of Abseil's flags library.
The rationale behind this is that glog includes/builds with gflags for
command line flag parsing and having more than one flag parsing library
active at the same time is asking for trouble.
PiperOrigin-RevId: 256982667
Change-Id: I9c5406cb9ef4458daebfec0b0713f9bddbf5c3ad
