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
