These are no longer providing useful information. There are still a
noticeable number of failures on Windows, but we've narrowed them down to
within SandboxBroker::LaunchApp.
MozReview-Commit-ID: 9srWLNZq1Wo
--HG--
extra : rebase_source : db44114a7623e75f9efd629046d2118748352ed1
This replaces some old Chromium code that tries to minimally disentangle
an arbitrary file descriptor mapping with simpler algorithm, for several
reasons:
1. Do something appropriate when a file descriptor is mapped to the same
fd number in the child; currently they're ignored, which means they'll
be closed if they were close-on-exec. This implementation duplicates
the fd twice in that case, which seems to be uncommon in practice; this
isn't maximally efficient but avoids special-case code.
2. Make this more generally applicable; the previous design is
specialized for arbitrary code running between fork and exec, but we
also want to use this on OS X with posix_spawn, which exposes a very
limited set of operations.
3. Avoid the use of C++ standard library iterators in async signal safe
code; the Chromium developers mention that this is a potential problem in
some debugging implementations that take locks.
4. In general the algorithm is simpler and should be more "obviously
correct"; more concretely, it should get complete coverage just by being
run normally in a debug build.
As a convenient side benefit, CloseSuperfluousFds now takes an arbitrary
predicate for which fds to leave open, which means it can be used in
other code that needs it without creating a fake fd mapping.
MozReview-Commit-ID: EoiRttrbrKL
--HG--
extra : rebase_source : 336e0ba9f56dc80f7347dc62617b4ad1efea7e7e
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This adds all the samples from the provided sample set to the CountHistogram's
storage, instead of just adding 1 sample of value 1. This change does not affect
code outside of GeckoView persistence since |AddSampleSet| is not used in other
places.
MozReview-Commit-ID: 9bE0M9dgrtE
--HG--
extra : rebase_source : c2147d084415518b02148daa83107045f2993c0f
There are three things we want to be true:
a) If the child sends a large value and the parent can't allocate enough space
for it we use an infallible allocation so the parent dies with an OOM.
b) If a fuzzer generates (huge-length, small-data) we don't try to allocate
huge-length bytes; knowing that the read will fail.
c) No fuzzer-specific branches in the core IPC serialization code.
Finally, this makes (huge-length, small-data) consistent with other cases where
the data is potentially truncated: ReadParam returns false.
MozReview-Commit-ID: 6nDKrw5z4pt
--HG--
extra : rebase_source : 58372d29139e9545a6ed2852c7243affeab6fdb7
This function is just pure bloat when it gets inlined, and it will
disappear on non-Nightly builds anyway. Make it MOZ_NEVER_INLINE so our
size statistics on Nightly are somewhat more reflective of our size
statistics on Release.
This replaces using file_util to open and unlink temporary files
(/dev/shm on Linux, $TMPDIR or /tmp otherwise) with the POSIX shm_open
API, or ashmem on Android (which doesn't implement shm_open).
glibc maps shm_open/shm_unlink to open and unlink in /dev/shm (as does
musl libc), so the Linux situation is mostly unchanged except we aren't
duplicating code from system libraries. Other OSes may (and some do)
use more efficient implementations than temporary files.
FreeBSD's SHM_ANON extension is used if available. Sadly, it's not
standard; it would make this patch much simpler if it were.
This patch changes the shm file names; they now start with "org.mozilla"
instead of "org.chromium" because the original Chromium code is mostly
gone at this point. When running as a Snap package, the required
filename prefix is added; other container/sandbox environments using
AppArmor to restrict the allowed filenames may need to be adjusted.
The shm names now include the creating process's pid, to allow
using sandboxing to prevent interfering with shm belonging to other
applications or other processes within the same browser instance.
MozReview-Commit-ID: 7PirIlcblh4
--HG--
extra : rebase_source : 550a0ab013429c29a57bde5c0e4593d9b426da8e
I've also manually verified that no other references to HANDLE_EINTR are
wrapping a close() in any less syntactically obvious way.
MozReview-Commit-ID: 3KkBwFIhEIq
--HG--
extra : rebase_source : 4e79a70b3be22a7721b6f85b19ee5a31c98df456
This is based on the current security/sandbox/chromium version of eintr_wrapper.h,
taken from upstream commit 937db09514e061d7983e90e0c448cfa61680f605.
I've edited it to remove some things that aren't relevant to us: the
debug-mode loop limit in HANDLE_EINTR, because we don't seem to be
having the problem it's meant to fix and it risks regressions, and
references to Fuchsia, which we don't (yet) support. I also kept the
original include guards (the file path has changed upstream).
What this patch *does* do is add IGNORE_EINTR and modernize the C++
slightly (using decltype instead of nonstandard typeof).
MozReview-Commit-ID: BO4uQL9jUtf
--HG--
extra : rebase_source : ab3343c6d93e0ce753859217a55af131a0c4ea68
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
This code isn't blocking anything, but it's dead and I don't think we
have any plans to use it.
MozReview-Commit-ID: KBoEfLceDns
--HG--
extra : rebase_source : 1eee3d961e249939f02d4cc40a707739eb2a596a
We're not using named shared memory, and supporting only anonymous
shared memory allows using other backends that are more compatible
with preventing a process from accessing any shared memory it wasn't
explicitly granted (i.e., sandboxing).
Specifically: SharedMemory::Open is removed; SharedMemory::Create no
longer takes a name, no longer has the open_existing option which doesn't
apply to anonymous memory, and no longer supports read-only memory
(anonymous memory which can never have been written isn't very useful).
This patch also fixes some comments in what remains of SharedMemory::Create.
MozReview-Commit-ID: 4kBrURtxq20
--HG--
extra : rebase_source : f6b1fb2fc79b6e9cdd251b3d9041036c0be503f9
This deletes some dead code and removes a dependency on the shared
memory object's name, which will be removed in the next patch (and is
always empty in our usage).
MozReview-Commit-ID: 1ub0nLCBucO
--HG--
extra : rebase_source : 6a29261e00b89773a2f2ace47303d9d9842c089b
This patch replaces the large -intPrefs/-boolPrefs/-stringPrefs flags with
a short-lived, anonymous, shared memory segment that is used to pass the early
prefs.
Removing the bloat from the command line is nice, but more important is the
fact that this will let us pass more prefs at content process start-up, which
will allow us to remove the early/late prefs split (bug 1436911).
Although this mechanism is only used for prefs, it's conceivable that it could
be used for other data that must be received very early by children, and for
which the command line isn't ideal.
Notable details:
- Much of the patch deals with the various platform-specific ways of passing
handles/fds to children.
- Linux and Mac: we use a fixed fd (8) in combination with the new
GeckoChildProcessHost::AddFdToRemap() function (which ensures the child
won't close the fd).
- Android: like Linux and Mac, but the handles get passed via "parcels" and
we use the new SetPrefsFd() function instead of the fixed fd.
- Windows: there is no need to duplicate the handle because Windows handles
are system-wide. But we do use the new
GeckoChildProcessHost::AddHandleToShare() function to add it to the list of
inheritable handles. We also ensure that list is processed on all paths
(MOZ_SANDBOX with sandbox, MOZ_SANDBOX without sandbox, non-MOZ_SANDBOX) so
that the handles are marked as inheritable. The handle is passed via the
-prefsHandle flag.
The -prefsLen flag is used on all platforms to indicate the size of the
shared memory segment.
- The patch also moves the serialization/deserialization of the prefs in/out of
the shared memory into libpref, which is a better spot for it. (This means
Preferences::MustSendToContentProcesses() can be removed.)
MozReview-Commit-ID: 8fREEBiYFvc
--HG--
extra : rebase_source : 7e4c8ebdbcd7d74d6bd2ab3c9e75a6a17dbd8dfe
Support for accept4 and arc4random_buf depends on which set of NDK
headers we're using. accept4 is supported for API >= 21 for unified and
non-unified headers. arc4random_buf is supported for API >= 21 if using
non-unified headers, and it's always supported if using unified headers
(the unified headers provide shims for API < 21).
MozReview-Commit-ID: FY8n5jWXB1K
--HG--
rename : ipc/chromium/src/third_party/libevent/patches/android-arc4random-buf.patch => ipc/chromium/src/third_party/libevent/patches/android-api-level.patch
extra : rebase_source : 45ec28ca03ba877d9e0911bde081df7d9cb2d3d2
Support for accept4 and arc4random_buf depends on which set of NDK
headers we're using. accept4 is supported for API >= 21 for unified and
non-unified headers. arc4random_buf is supported for API >= 21 if using
non-unified headers, and it's always supported if using unified headers
(the unified headers provide shims for API < 21).
MozReview-Commit-ID: FY8n5jWXB1K
--HG--
rename : ipc/chromium/src/third_party/libevent/patches/android-arc4random-buf.patch => ipc/chromium/src/third_party/libevent/patches/android-api-level.patch
extra : rebase_source : a8974cb1e8e71a8c951754ca9902fff28c099031
Namespace isolation is now handled by using clone() at process creation
time, rather than calling unshare.
pthread_atfork will no longer apply to sandboxed child processes.
The two significant uses of it in Firefox currently are to (1) make
malloc work post-fork, which we already avoid depending on in IPC and
sandboxing, and (2) block SIGPROF while forking, which is taken care of;
see SandboxFork::Fork for details. Note that if we need pthread_atfork
in the future it could be emulated by symbol interposition.
clone() is called via glibc's wrapper, for increased compatibility vs.
invoking the syscall directly, using longjmp to recover the syscall's
fork-like semantics the same way Chromium does; see comments for details.
The chroot helper is reimplemented; the general approach is similar,
but instead of a thread it's a process cloned with CLONE_FS (so the
filesystem root is shared) from the child process before it calls
exec, so that it still holds CAP_SYS_CHROOT in the newly created user
namespace. This does mean that it will retain a CoW copy of the
parent's address space until the child starts sandboxing, but that is a
relatively short period of time, so the memory overhead should be small
and short-lived.
The chrooting now happens *after* the seccomp-bpf policy is applied;
previously this wasn't possible because the chroot thread would have
become seccomp-restricted and unable to chroot. This fixes a potential
race condition where a thread could try to access the filesystem after
chrooting but before having its syscalls intercepted for brokering,
causing spurious failure. (This failure mode hasn't been observed in
practice, but we may not be looking for it.)
This adds a hidden bool pref, security.sandbox.content.force-namespace,
which unshares the user namespace (if possible) even if no sandboxing
requires it. It defaults to true on Nightly and false otherwise, to
get test coverage; the default will change to false once we're using
namespaces by default with content.
MozReview-Commit-ID: JhCXF9EgOt6
--HG--
rename : security/sandbox/linux/LinuxCapabilities.cpp => security/sandbox/linux/launch/LinuxCapabilities.cpp
rename : security/sandbox/linux/LinuxCapabilities.h => security/sandbox/linux/launch/LinuxCapabilities.h
extra : rebase_source : f37acacd4f79b0d6df0bcb9d1d5ceb4b9c5e6371
