Allow access to Apple's Metal shader language compiler in our content process sandbox. Limit the sandbox policy change to 10.14 and newer OS versions to reduce risk given that problems have only been reported on 10.14.5.
Differential Revision: https://phabricator.services.mozilla.com/D28904
--HG--
extra : moz-landing-system : lando
If the system doesn't support seccomp-bpf, the parent process won't
try to set up sandboxing, but the child process has a separate check that
didn't test for this, and ends up failing a release assertion (in
SandboxReporterClient, but we also release-assert that installing the
seccomp-bpf policy succeeds).
This patch just fixes the child-side conditional to match the intended
behavior, but in the long term we should consider redesigning SandboxInfo
to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D27624
--HG--
extra : moz-landing-system : lando
When the test font is activated, the notification of the font configuration change
may be handled asynchronously by content processes, so that it's possible the content
process has not yet handled the update at the point when registerFont() detects the
change and returns to the test script.
(This issue becomes more acute with the upcoming shared-font-list system, where the
OS notification is not handled by the content process at all; it's only handled by
the parent process, which then notifies content processes *after* it has updated the
font list. So there's an inherent latency between the update being recognized by the
chrome process - and therefore "ready" as far as the test script is concerned - and
content processes receiving and handling the change.)
To handle this, we can explicitly wait for the width of the rendered content to change,
which will indicate that the font configuration change has been handled by the content
process.
Differential Revision: https://phabricator.services.mozilla.com/D26570
--HG--
extra : moz-landing-system : lando
Allow read access to /System/Library for accessing system libraries.
Depends on D26397
Differential Revision: https://phabricator.services.mozilla.com/D26626
--HG--
extra : moz-landing-system : lando
Add the crash reporter port to the utility process sandbox so that crash reports can be saved for processes using the utility sandbox with early sandbox init.
At this time, the RDD process is the only process using the utility sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D26228
--HG--
extra : moz-landing-system : lando
When the RDD process sandbox is started at launch, assert the sandbox has been enabled in the Init message.
Change AssertMacSandboxEnabled() to use the undocumented sandbox_check() function instead of sandbox_init().
Differential Revision: https://phabricator.services.mozilla.com/D22414
--HG--
extra : moz-landing-system : lando
Move sandbox early start logic to GeckoChildProcessHost.
Move sandbox CLI param logic into MacSandboxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D22409
--HG--
extra : moz-landing-system : lando
Remove the unused plugin binary path and app binary path parameters and cleanup file path permissions.
Explicitly allow access to launchservicesd to allow SetProcessName() to work when the sandbox is started during startup.
Differential Revision: https://phabricator.services.mozilla.com/D22408
--HG--
extra : moz-landing-system : lando
Move sandbox policies for different process types into their own files.
Create a new "utility" policy cloned from the GMP policy to be used for basic utility-type processes.
Use the utility policy for the RDD process.
Differential Revision: https://phabricator.services.mozilla.com/D22405
--HG--
extra : moz-landing-system : lando
Added files to UNIFIED_SOURCES and removed conflicts. Files that required flags still remain in SOURCES. SOURCES use "StrictOrderingOnAppendListWithFlagsFactory" base class and UNIFIED_SOURCES use "StrictOrderingOnAppendList" base class. As of now I do not think there is an option to add flags for the later. So the files requiring flags are kept in SOURCES.
Differential Revision: https://phabricator.services.mozilla.com/D23795
--HG--
extra : moz-landing-system : lando
clang-cl only acts on five MSVC warning flags: 7219c7e9af/clang/include/clang/Driver/CLCompatOptions.td (L188-L197)
With MSVC now unsupported, most -wdNNNN have no effect and can be removed.
This patch converts the five supported warnings to their clang spellings, as preparation for a subsequent patch that will remove all remaining `[/-]w[edo][0-9]{4}`.
Differential Revision: https://phabricator.services.mozilla.com/D22582
--HG--
extra : moz-landing-system : lando
The seccomp-bpf policy is currently just the "common" policy with no
additions (but with the fixes in bug 1511560 to enable shared memory
creation). The file broker policy allows shared memory creation and
nothing else. The namespace setup is the same as for GMP (i.e., as
restrictive as we currently can be).
The sandbox can be turned off for troubleshooting by setting the
environment variable MOZ_DISABLE_RDD_SANDBOX, similarly to the other
process types.
Tested against https://demo.bitmovin.com/public/firefox/av1/ with the
necessary prefs set.
Depends on D20895
Differential Revision: https://phabricator.services.mozilla.com/D14525
--HG--
extra : moz-landing-system : lando
File descriptors are sometimes dup()ed in the process of communicating
them over IPC; some of this may be unnecessary (due to insufficient
use of move-only types), but dup() is relatively harmless. It was
previously allowed for both content and GMP, so this doesn't change
anything.
The handling of ftruncate is a little complicated -- it's used for IPC
shared memory, but only when creating segments; so GMP doesn't allow
it and should continue not allowing it, but content needs it and RDD
will as well. As a result, the subclass indicates if it will be needed.
Note that even when we have memfd_create support (bug 1440203),
ftruncate is still necessary even though brokering may not.
Depends on D14523
Differential Revision: https://phabricator.services.mozilla.com/D14524
--HG--
extra : moz-landing-system : lando
The sandbox broker uses socketpair to construct the per-request channels
over which responses are sent; thus, if and only if the policy will be
using brokering, it will allow socketpair as safely as possible (i.e.,
denying datagram sockets if possible).
Depends on D14522
Differential Revision: https://phabricator.services.mozilla.com/D14523
--HG--
extra : moz-landing-system : lando
madvise is used by our malloc (and probably others), and mprotect is
used with shared memory, including when created by another process, so
the common policy should include those rules.
Depends on D14521
Differential Revision: https://phabricator.services.mozilla.com/D14522
--HG--
extra : moz-landing-system : lando
This will allow other policies to use brokering if needed (e.g., RDD and
similar utility processes may need to access /dev/shm to create shared
memory). The concrete policy class can deny filesystem access completely
(matching the current behavior of the GMP policy) by passing nullptr to
the superclass constructor instead.
Depends on D14520
Differential Revision: https://phabricator.services.mozilla.com/D14521
--HG--
extra : moz-landing-system : lando
ContentSandboxPolicy currently allows direct filesystem access if it
isn't given a broker client; this is a legacy design from the B2G era,
before the current idea of "sandbox level". With this patch, it allows
filesystem access at level 1, and above that it requires brokering.
This is both to reduce the opportunities for accidentally having a
too-permissive sandbox and to prepare for refactoring the broker glue in
bug 1511560.
Depends on D14519
Differential Revision: https://phabricator.services.mozilla.com/D14520
--HG--
extra : moz-landing-system : lando
Level 1 is meant to enable some seccomp-bpf filtering, but still allow
direct access to the filesystem, and level 2 is where brokering starts.
This was accidentally broken in 1365257 (making "level 1" act like level
2); this patch fixes that.
This feature obviously isn't used much given how long nobody noticed it was
broken, but it's useful to have around for troubleshooting, and it's
actually easier to fix it than edit it out of the documentation.
Differential Revision: https://phabricator.services.mozilla.com/D14519
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Allow file-write-unlink in ~/Library/Preferences/Macromedia/Flash Player to allow changes made in the Flash Global Settings panel to persist.
Differential Revision: https://phabricator.services.mozilla.com/D19217
--HG--
extra : moz-landing-system : lando
