For OSS, this change should be mostly a no-op. Visible edits are due to
changed order of code and/or includes.
PiperOrigin-RevId: 394177395
Change-Id: I1d32f9fd175579e8f05c051b1307953b249d139d
This mainly a debugging facility.
It makes diagnosing problems where sandboxed process just randomly exits whereas unsandboxed one runs to completion due to differences in the setup/environment much easier.
PiperOrigin-RevId: 391005548
Change-Id: Ia19fe6632748da93c1f4291bb55e895f50a4e2b0
Otherwise starting forkserver multiple times will result in zombie processes lingering around.
PiperOrigin-RevId: 388926497
Change-Id: Ia9947cce3d9e909edd709b0d3525e1ae8b8bbc51
Also really own `exec_fd_` as previously if the executor is destructed without calling `StartSubProcess` the file descriptor would leak.
PiperOrigin-RevId: 388901766
Change-Id: I6bbb15ced37a0a832ec5a5228452a3d54ef46ee9
This was missing a friend declaration in order to actually compile.
It's now being used in the "stringop" example, so we test it as well.
Drive-by:
- Do not copy the proto's bytes the constructor, but use `std::move`
PiperOrigin-RevId: 387774353
Change-Id: Ic8824af911ac744e2e68130e1f4673c4dddd4939
Calling `Terminate()` issues additional syscalls that may clobber the `errno`
value. Reordering the log statements ensures we actually log the initial error
in `read()`/`write()`.
PiperOrigin-RevId: 387576942
Change-Id: I0f9c8c6001e6dc4ca098abe02cd251029f92a737
1. In many cases, sandboxes need to allow /proc/stat and /proc/cpuinfo so that
get_nprocs(3) will work; otherwise, per-CPU logic can't determine how many CPUs
there are. Unfortunately, some of those sandboxes also disable namespaces. The
solution is to provide two functions: AllowRestartableSequencesWithProcFiles(),
which allows syscalls and files; and AllowRestartableSequences(), which allows
syscalls only. Sandboxes should usually call the former; sandboxes that disable
namespaces should instead call the latter and are responsible for allowing the
files via the deprecated Fs mechanism.
2. Make the mmap(2) policy evaluate prot AND flags, not prot OR flags.
3. Order the code and the comments identically for better readability.
PiperOrigin-RevId: 386414028
Change-Id: I016b1854ed1da9c9bcff7b351c5e0041093b8193
Ideally, we'd seal the embedded SAPI binary using fcntl(). However, in rare
cases, adding the file seals `F_SEAL_SEAL | F_SEAL_SHRINK | F_SEAL_GROW |
F_SEAL_WRITE` results in `EBUSY` errors.
This is likely because of an interaction of `SEAL_WRITE` with pending writes
to the mapped memory region (see `memfd_wait_for_pins()` in Linux'
`mm/memfd.c`). Since `fsync()` is a no-op on memfds, it doesn't help to
ameliorate the problem.
On systems where it is enabled, ksmd might also be a source of pending writes.
PiperOrigin-RevId: 385741435
Change-Id: I21bd6a9039be4b6298774e837ce3628180ed91a8
The existing function signature took a `unique_ptr<>` owning a vector, and
took `nullptr` to mean an empty set of capabilities. This is more naturally
modeled by taking the vector directly and `std::move`-ing it.
PiperOrigin-RevId: 384214849
Change-Id: I177f04a06803ae00429b19a1f3f12e7be04d2908
- Assign to `*mutable_XXX()` instead of looping
- Use a const ref for capabilities
PiperOrigin-RevId: 384192675
Change-Id: I4db3d0c8ce0d7f6acc9fd486a2409962516b5fe7
This bug only manifests if a lot of fds are open when global forkserver is started.
If the allocated exec_fd number was equal Comms::kSandbox2ClientCommsFD then it would be replaced by the comms fd and result in EACCESS at execveat.
PiperOrigin-RevId: 380805414
Change-Id: I31427fa929abfc60890477b55790cc14c749f7f5
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
Depending on architecture and optimization level, the compiler may choose to
not generate full stack frames, even with no-inline and no tail-call
attributes.
PiperOrigin-RevId: 372339987
Change-Id: I42043131bbb6092ff234e80ae9047f7a2bf31161
This fixes tests for PPC, where the tail-call optimization would consistently
remove 'violate()' from the stack trace.
PiperOrigin-RevId: 371103794
Change-Id: Ifb1a7d588a455041a6b0f3c763276ed44de47e60
On x86 `long double` has 10 bytes of meaningful data, but `sizeof(long double)` is 16 - the remaining bytes are random garbage.
Roll forward after fixing a bug in the original commit.
PiperOrigin-RevId: 368170639
Change-Id: I4a1d2d95b92eed6b71c37145726f7320cfc00ba0
On x86 `long double` has 10 bytes of meaningful data, but `sizeof(long double)` is 16 - the remaining bytes are random garbage.
PiperOrigin-RevId: 367423349
Change-Id: I769b3444ce4fa60f941ccd2115b0b09ccc809f13
This is needed for some compiler versions where `absl::string_view` == `std::string_view`.
PiperOrigin-RevId: 367392064
Change-Id: Id91d23510501df4745f386475ef9049d94062e1b
This changes the workflow definition so that we always try to install
compiler toolchains that we need.
See https://github.com/actions/virtual-environments/issues/2950 for more
context.
Drive-by:
- Mini fix to enable compilation under Clang 6.0
Signed-off-by: Christian Blichmann <cblichmann@google.com>
Now unwinding will properly handle binaries inside bind-mounted directories.
Drive-by:
- Get rid of n^2 path handling
- Get rid of namespace alias
PiperOrigin-RevId: 358353666
Change-Id: Ieec7690ec6a1ae6d358de375220566b69e8cb094
Bazel readily enforces header visiblity for each target, CMake is more lenient.
PiperOrigin-RevId: 355407845
Change-Id: Ic59fa2162db8456d4c5cf4205c0fe42cc79874a9
The former is to fix compilation on GCC 7, the latter to satisfy MSAN.
PiperOrigin-RevId: 355114355
Change-Id: I5c89a65df16fe9338bcfa24b2e48c246d240ce62
Using C++17 means we can get rid of many `#ifdef`s by using `if constexpr`.
This way, we ensure that both branches compile and still retain zero runtime
overhead.
Note that open source builds of Sandboxed API do not ship with sanitizer
configurations yet. This will be added in follow-up changes.
PiperOrigin-RevId: 354932160
Change-Id: I3678dffc47ea873919f0a8c01f3a7d999fc29a5b
Also accept `absl::string_view` and `absl::Span<const std::string>` arguments.
Drive-by:
- Move using declaration into namespace
PiperOrigin-RevId: 354271016
Change-Id: Iadd873377e51cac7fa3800aab1f9e85ff94bd4e9
Only externally visible changes should be a few changed includes as well as
some formatting changes.
PiperOrigin-RevId: 353226662
Change-Id: Iebf5be13774efcbd94c5d5a17b9b27e47275b229
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
This also allows to install `libclang1` instead of `libclang1-dev` as
one of the build dependencies on Ubuntu/Debian.
Signed-off-by: Christian Blichmann <cblichmann@google.com>
This change enables support for 32-bit ARM, as used by embedded controllers and older phones.
Note: This does not support 32-bit sandboxees on AArch64. Both sandboxee and host code must have the same bitness.
PiperOrigin-RevId: 347835193
Change-Id: I6395882677530f9862f118d2dc10230a61049836
Because any change that touches continuous integration needs a companion o.O
PiperOrigin-RevId: 347769780
Change-Id: I20525aaac2ce41c48f619b641baa31e880432e50
- Ubuntu 18.04 ships with GCC 7, which needs `std::move()` when returning an `absl::StatusOr<>`
- Ignore C++ AST nodes of type `cindex.TypeKind.UNEXPOSED` in Python generator
- Remove default values in `ubuntu-cmake.yml`
PiperOrigin-RevId: 347605109
Change-Id: Ibe167249ecf4ef1af1654d63c2e067fc02e5782d
This allows resource-constrained environments to benefit from the
space savings of dynamic linking. This is not meant to be used in
the general case.
PiperOrigin-RevId: 347398828
Change-Id: Ia634959148a31159878f48c44255dd733424a2b8
FS checks are an internal feature that has been deprecated for a while in
favor of user namespaces.
PiperOrigin-RevId: 347378761
Change-Id: I1d7956cecd6db47b2b96fdedaada0b2a36f9b112
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
- Bazel: Use "incompatible" flag to fix fully static linking. The flag will
become the default in Bazel 4.0.
- Bazel: Deduplicate features into `FULLY_STATIC_FEATURES` variable
- CMake: Remove the testcase properties. `sapi::base` already sets
`POSITION_INDEPENDENT_CODE`. Note that `-pie` is incompatible with `-static`
and `-static-pie` requires GCC 8 and GLIBC 2.27.
PiperOrigin-RevId: 346952478
Change-Id: I7a317c90a3bec9691b13df1a00e3fddf4481df4d
The default policy causes immediate termination of a sandboxee that
calls `bpf`(2).
This does not allow for try-call use of `bpf()` to test for optional
features.
To support such try-call use cases, sandboxes would like to say:
```
sandbox2::PolicyBuilder builder;
builder.BlockSyscallWithErrno(__NR_bpf, EPERM);
```
but this doesn't work because the default policy unconditionally treats
`bpf()` as a sandbox violation.
Remove the bpf violation check from the policy if `bpf()` is explicitly
blocked with an errno.
PiperOrigin-RevId: 345239389
Change-Id: I7fcfd3a938c610c8679edf8e1fa0238b32cc9db4
The lookup is not on the hot path and this removes the SYSCALLS_UNUSED macros.
PiperOrigin-RevId: 344240762
Change-Id: I324bd798945851ac0b92e257206525eab4ec36e5
The semantics of the example remain unchanged. This change is in preparation
for the new Clang based header generator, which will parse most files in C++
mode. `ptrace`'s first argument cannot me implicitly converted from `int` in
C++.
PiperOrigin-RevId: 343280691
Change-Id: Ibc5318b19a48f1dad441e7dcdc318dc5ea6837f6
Updates syscall arguments mostly according to this list and more recent kernel sources:
https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md#x86_64-64_bit
The list includes some more syscalls that were recently added.
Follow-up changes will do the same for x86-32, POWER and AArch64.
PiperOrigin-RevId: 341016698
Change-Id: If1771fd37a47b227ca8f572704a64190e4621a38
No need for the smart pointer indirection when an `std::vector` can also hold
the BPF policy.
PiperOrigin-RevId: 340809220
Change-Id: I8a63567e8042d9ff875cba739e8552db87b6901a
If the sandboxer calls `IPC::EnableLogServer()` (and modifies the sandbox policy
accordingly), sandbox logs will be sent back to the sandboxer.
PiperOrigin-RevId: 340663308
Change-Id: I5e8d89314178dfd1b49fc25b8cd2dd02642be43a
This change allows us to emit forward declarations to classes that are
templated. For headers generated by the proto compiler this is sometimes
necessary.
Note:
- This will only emit types for a single level of template instantiations.
That is, template template arguments are not supported.
- Typedefs only occurring in template arguments will be fully desugared
and thus will not be available under their aliased name in the generated
API code. This is consistent with the Python based generator (which
does not emit these at all and relies on text extraction).
Signed-off-by: Christian Blichmann <cblichmann@google.com>
This change includes a small refactoring to remember which types the generator
has already seen during header generations. Otherwise we may loop indefinitely
on certain complex types. One such type is `std::FILE` in Clang's libc++.
PiperOrigin-RevId: 335589238
Change-Id: I5bbe03b6c7fc89c743163f5534075d7912ed4e58
- Use a `constexpr inline` string constant for the forkserver env var
- Add annotation for the comms channel mutex
PiperOrigin-RevId: 335395005
Change-Id: Ic058c19c3704f182aa7ed7b8e8964b2fc5082800
