Switch to ForkWithFlags for InitProcess (it will not reset coverage).
Explicitly dump coverage after initial namespace setup.
Return instead of exiting from libunwind sandbox.
PiperOrigin-RevId: 563368599
Change-Id: I3b764db015a71bd091ee7b4b5b614281cbb84832
This removes dependency on unwind from forkserver,
which should reduce binary size for all the custom forkservers (also the SAPI generated ones).
Unwind was only ever used by the global forkserver anyhow
PiperOrigin-RevId: 557921074
Change-Id: Iea4904da0506fee5a00f970538f512cba7b02326
Also make sure we don't kill everything (with a `kill(-1, SIGKILL)`) if reading the pid fails.
PiperOrigin-RevId: 536371566
Change-Id: I17f6ae36b73ec43735709ff16d276abaebb00d44
Unotify based monitor should bring big performance wins
if the sandboxee heavily uses threading or signals.
Some of the features are not supported in that mode:
- execveat is always allowed instead of just the initial one
- stack traces are not collected on normal exit or if the process is terminated by signal
PiperOrigin-RevId: 515040101
Change-Id: Ia5574d34b4ff7e91e3601edb8c9cb913e011fbf6
Libunwind sandbox no longer needs to join sandboxee's userns.
This cleans up a lot of special handling for the libunwind sandbox.
PiperOrigin-RevId: 503140778
Change-Id: I020ea3adda05ae6ff74137b668a5fa7509c138f8
This change allows Sandbox2 to change how the default FD for comms is chosen.
PiperOrigin-RevId: 479526309
Change-Id: I69add85a244bc0385eaa164ab0ea3b036503c6d3
Recenly, Debian based distribution kernels started activating the Tomoyo Linux
Security Module by default. Even if it is not used, this changes the behavior
of `/dev/fd` (pointing to `/proc/self/fd` by default), which Sandbox2 needs during
`execveat()`.
As a result, Sandbox2 and Sandboxed API always fail without one of the following
conditions
- `/proc` mounted within the sandboxee
- `/dev` mounted
- `/dev/fd` symlinked to `/proc/self/fd` in the sandboxee's mount namespace
Some code pointers to upstream Linux 5.12.2:
- https://elixir.bootlin.com/linux/v5.12.2/source/fs/exec.c#L1775
- https://elixir.bootlin.com/linux/v5.12.2/source/security/tomoyo/tomoyo.c#L107
- https://elixir.bootlin.com/linux/v5.12.2/source/security/tomoyo/domain.c#L729
To find out whether your system has Tomoyo enabled, use this command, similar to
what this change does in code:
```
$ cat /sys/kernel/security/lsm | grep tomoyo && echo "Tomoyo active"
capability,yama,apparmor,tomoyo
Tomoyo active
```
The config setting `CONFIG_DEFAULT_SECURITY` controls which LSMs are built into
the kernel by default.
PiperOrigin-RevId: 372919524
Change-Id: I2181819c04f15f57d96c44ea9977d0def4a1b623
This change should make it less confusing where utility code comes from.
Having it in two places made sense when we were debating whether to publish
Sandbox2 separately, but not any longer.
Follow-up changes will move `sandbox2/util.h` and rename the remaining
`sandbox2/util` folder.
PiperOrigin-RevId: 351601640
Change-Id: I6256845261f610e590c25e2c59851cc51da2d778
The defined raw logging macros should be compatible with Abseil and
we can remove our version once Abseil releases theirs.
PiperOrigin-RevId: 347354273
Change-Id: I178a89cfd2e19bcd707a06fa9dfd7b767e2b654b
