On Linuxen without getrandom(), Rust (and Firefox broadly) uses /dev/urandom
as a fallback. Rust uses it for a few things, notably hashmaps... and will
panic if it can't use it.
Differential Revision: https://phabricator.services.mozilla.com/D174336
This defines MOZ_CONTENT_TEMP_DIR to make it easier to track this in the code.
It also uses this to guard some Linux specific uses.
Differential Revision: https://phabricator.services.mozilla.com/D168596
As discussed in the last patch, allowing `fstatfs` will also make
`statfs` work on any path that the process could open for reading
(subject to sandbox policy).
Differential Revision: https://phabricator.services.mozilla.com/D157542
We have code to handle `statfs` calls in content processes by
intercepting them and calling `open` and `fstatfs` instead; the former
is then recursively intercepted and brokered. This patch moves that
feature into the common policy, but does not allow `fstatfs` in any
other sandbox types (yet; see next patch). This doesn't affect security
because the caller could have attempted the `open` and `fstatfs`
syscalls itself.
Differential Revision: https://phabricator.services.mozilla.com/D157541
We uninstall signal handlers in child processes after clone(), because
they probably won't do the right thing if invoked in that context.
However, the current code also resets signals which were ignored;
if that disposition was set by an outside program like `nohup`, the
expectation is that it should be inherited. This patch omits those
signals when resetting handlers (similar to what `exec` does).
Differential Revision: https://phabricator.services.mozilla.com/D151336
`strerror` is async signal unsafe, and we're using it in contexts where
that's a problem: in particular in the child process after `clone()`ing,
where it can deadlock if it takes locks the parents' other threads had
held (or cause other undefined behavior), but also in the SIGSYS handler
if it's nested inside an async signal. It's also thread-unsafe.
This is mostly a mechanical replacement with the new `SANDBOX_LOG_ERRNO`
or `SANDBOX_LOG_WITH_ERROR`; two messages had the error string in the
middle and have been adjusted.
Differential Revision: https://phabricator.services.mozilla.com/D152099
This adds two new logging macros, which are intended to be async signal
safe:
* `SANDBOX_LOG_ERRNO`, which appends the error similarly to `perror` but
uses the error identifier (e.g., `EINVAL` instead of `Invalid argument`).
Unlike `perror`, formatting directives are available as for `SANDBOX_LOG`.
* `SANDBOX_LOG_WITH_ERROR` is the same thing but the error number is the
first argument instead of using `errno`; this is useful for newer POSIX
APIs which return an error number.
This will be used in the next patch to replace the existing use of
`strerror`, which is not async signal safe (or thread-safe).
Differential Revision: https://phabricator.services.mozilla.com/D152098
Originally this was written for B2G and used the Android logging
facility, which (like syslog) includes a severity level. However, all
current usage is on desktop where we just write to stderr, and there was
never much demand to add support for any log levels besides "error".
More importantly for the current situation, renaming the macro to
`SANDBOX_LOG` avoids confusion between `SANDBOX_LOG_ERROR` and
`SANDBOX_LOG_ERRNO` (or `SANDBOX_LOG_ERROR_ERRNO` or whatever).
Differential Revision: https://phabricator.services.mozilla.com/D152097
Two minor things I noticed while converting the existing sandbox logging:
1. One call site was using %u, but that doesn't exist in this printf
dialect, only %d; signedness is determined by the actual argument
type via template magic.
2. POSIX functions that return an error number just return the number;
there was one place that was negating it before use, as if it had
come from the Linux syscall ABI.
Differential Revision: https://phabricator.services.mozilla.com/D152096
On multi-GPU systems, even though the GPU we're going to use for
accelerated video decoding is driven by Mesa, sometimes the nvidia
proprietary driver can be loaded and attempt to probe devices. This
patch attempts to make the sandbox policy quietly return errors for
those syscalls, instead of treating them as unexpected (and crashing on
Nightly).
Differential Revision: https://phabricator.services.mozilla.com/D149652
There are two parts to this patch; both affect only Linux:
1. The GMP sandbox policy is adjusted to allow certain syscalls used in
shared memory creation (ftruncate and fallocate). However, the file
broker is not used; the process still has no access to files in /dev/shm.
2. The profiler is not initialized for GMP processes unless memfd_create
is available (so the process can create shared memory to send
profiling data back, without filesystem access), or the GMP sandbox
is disabled (either at runtime or build time).
As of this patch, profiling GMP processes on Linux should succeed on
distros with kernel >=3.17 (Oct. 2014), but native stack frames won't
have symbols (and may be incorrectly unwound, not that it matters much
without symbols); see the bug for more info. Pseudo-stack frames and
markers should work, however.
Differential Revision: https://phabricator.services.mozilla.com/D148470
The profiler may try to readlink `/proc/self/exe` to determine the
executable name; currently, its attempt to get information about loaded
objects is broken for other reasons, so this isn't helpful. Thus, this
patch has it fail with `EINVAL` (meaning "not a symbolic link) instead of
being treated as unexpected.
(In the future, if we need to, we could simulate that syscall by
recording the target of `/proc/self/exe` before sandboxing, and
recognizing that specific case in a trap function.)
Differential Revision: https://phabricator.services.mozilla.com/D148469
The patch for bug 1769499 lets the RDD process create a headless EGL
context using GBM, which needs access only to the GPU device files, not
the display server. This means that the X11 access recently added in
bug 1769182 can be turned back off.
Differential Revision: https://phabricator.services.mozilla.com/D147792
This patch mostly turns on the features set up by the earlier patches:
allow connecting to the X server and reading various related things
(.Xauthority, GPU device info in sysfs, etc.). It also turns off Mesa's
shader cache in the RDD process; that shouldn't be needed here, and
disabling it lets us avoid dealing with a few things in the sandbox
policy that we'd rather not (e.g., `getpwuid`).
Differential Revision: https://phabricator.services.mozilla.com/D146275
This patch moves a lot of text but the idea is relatively simple and
no functional change is intended: factor out the parts of the content
sandbox policy needed to create and use an EGL context under X11.
(The `AddDriPaths` function already has some of the dependencies in a
conveniently separated form, but there are others.)
Differential Revision: https://phabricator.services.mozilla.com/D146274
These syscalls (at least send/recv) are used by X11 client libraries, and
allowing them doesn't really change anything about security or attack
surface, because they're strict subsets of sendmsg/recvmsg which we
already allow everywhere for use by IPC. So, this patch allows them in
all process types instead of only content.
Differential Revision: https://phabricator.services.mozilla.com/D146273
We're going to want to let the RDD process make a (brokered) connection
to a local X server, but the seccomp-bpf plumbing for that mostly lives
in the content process sandbox policy. This moves it into the common
policy, and subclasses can opt in.
Differential Revision: https://phabricator.services.mozilla.com/D146272
The arguments to the SandboxPolicyCommon contructor will get more
complicated as more optional features are added (e.g., the one added in
the next patch), and they're basically just mapped to boolean member
variables, so this patch lets the subclasses set them directly, to keep
things simpler and more readable.
Differential Revision: https://phabricator.services.mozilla.com/D146271
