Bug 1808320 - Filter the flags argument of pipe2(). r=gcp Differential Revision: https://phabricator.services.mozilla.com/D166754

Bug 1805331 - Disable TestDetouredCallUnwindInfo under MOZ_CODE_COVERAGE in TestDllInterceptor. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D164553

Bug 1802513 - Allow readlink(/proc/self/exe) in Utility sandbox for FFVPX r=gcp Differential Revision: https://phabricator.services.mozilla.com/D163227

Bug 1799562 - update version of Cylance to blocklist r=gcp Differential Revision: https://phabricator.services.mozilla.com/D162693

Bug 1794064 - Block older crash-prone versions of Avast Antivirus r=gcp Differential Revision: https://phabricator.services.mozilla.com/D158836

Bug 1790419 - cache BinaryPath value on OpenBSD r=gcp Differential Revision: https://phabricator.services.mozilla.com/D157554

Bug 1780312 - Part 2: Allow fstatfs in the Linux RDD sandbox policy. r=gcp 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

Bug 1780312 - Part 1: Move the statfs replacement into the common sandbox policy. r=gcp 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

Bug 1778052 - Don't reset ignored signals when starting a sandboxed child process on Linux. r=gcp 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

Bug 1782027 - Fix bustage in simulated early-beta Windows builds r=gcp ... which was entirely due to a trivial error on my part. Differential Revision: https://phabricator.services.mozilla.com/D153109

Bug 1780312 - Turn off the Linux nvidia driver's shader cache in the RDD process. r=gcp We were already turning off Mesa's shader cache in the RDD process, because it's not useful given that we're only using video codec acceleration and moving images around, and it does a few things related to trying to access the cache that the sandbox would have to accomodate. This patch does the equivalent thing for the nvidia proprietary driver; we don't support it for media codec acceleration, but it can still be loaded in that process (e.g., on multi-GPU systems) and it's trying to call `statfs` on startup which may be related. Differential Revision: https://phabricator.services.mozilla.com/D152932

Bug 1778052 - Don't reset ignored signals when starting a sandboxed child process on Linux. r=gcp 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

Bug 1728871 - P3. Add the URLCLASSIFIER_UPDATE_REMOTE_SETTING_RESULT telemetry r=gcp We can use this telemetry to track the statistics of using RemoteSettings to serve Safe Browsing data. The can help us understand if we can roll out this feature to more users. Depends on D135990 Differential Revision: https://phabricator.services.mozilla.com/D136107

Bug 1728871 - P2. Add UrlClassifierRemoteSettingsService testcases r=gcp Depends on D135989 Differential Revision: https://phabricator.services.mozilla.com/D135990

Bug 1728871 - P1. Add UrlClassifierRemoteSettingsService to serve update data over RemoteSettings r=gcp,leplatrem This patch implements UrlClassifierRemoteSettingsService to get SafeBrowsing data (protocol v2) from RemoteSettings instead of from the Shavar server. This is only used by data provided by Mozilla. To distinguish if the data should be coming from RemoteSettings or Shavar, We added a custom scheme "moz-sbrs" to denote that the data should be retrieved from Remote Setting. This is done by changing the value of pref "browser.safebrowsing.provider.mozilla.updateURL" to something like "moz-sbrf://tracking-protection-list". (Note that the hostname is not used at this point). The goal of this patch is to make the new architecture compatible with the original Safe Browsing design. So we don't notify Safe Browsing there is new data available (via "sync" event of RemoteSettings). We still follow how Safe Browsing periodically checks whether there is a newer version of list. Note. This patch changes the flow comparing with how we usualy receive SafeBrowsing response from Shavar. In Shavar case, the list data response usually comes with "n:21600\ni:listname1\nu:redirectURL1\ni:listname2\nu:redirectURL2 ..." first. And then we fetch the data again from the redirectURL for each list. But in the current implementation, responses don't contain redirectURL anymore (since we already have the data). So the mocked response will contain all the data needed in one response. For example: "n:21600\ni:listname1\n:chunkdata1\ni:listname2\n:chunkdata2...". Differential Revision: https://phabricator.services.mozilla.com/D135989

Bug 1777910 - Adjust Mesa environment variables for change/deprecation in 22.1. r=gcp Mesa 22.1.0 changed the env var name MESA_GLSL_CACHE_DISABLE to MESA_SHADER_CACHE_DISABLE; it still accepts the old name, but prints a deprecation warning. If we set both env vars, then we can support both old and new Mesas correctly (the warning won't be printed if the new env var is also set). Differential Revision: https://phabricator.services.mozilla.com/D151094

Bug 1728871 - P3. Add the URLCLASSIFIER_UPDATE_REMOTE_SETTING_RESULT telemetry r=gcp We can use this telemetry to track the statistics of using RemoteSettings to serve Safe Browsing data. The can help us understand if we can roll out this feature to more users. Depends on D135990 Differential Revision: https://phabricator.services.mozilla.com/D136107

Bug 1728871 - P2. Add UrlClassifierRemoteSettingsService testcases r=gcp Depends on D135989 Differential Revision: https://phabricator.services.mozilla.com/D135990

Bug 1728871 - P1. Add UrlClassifierRemoteSettingsService to serve update data over RemoteSettings r=gcp,leplatrem This patch implements UrlClassifierRemoteSettingsService to get SafeBrowsing data (protocol v2) from RemoteSettings instead of from the Shavar server. This is only used by data provided by Mozilla. To distinguish if the data should be coming from RemoteSettings or Shavar, We added a custom scheme "moz-sbrs" to denote that the data should be retrieved from Remote Setting. This is done by changing the value of pref "browser.safebrowsing.provider.mozilla.updateURL" to something like "moz-sbrf://tracking-protection-list". (Note that the hostname is not used at this point). The goal of this patch is to make the new architecture compatible with the original Safe Browsing design. So we don't notify Safe Browsing there is new data available (via "sync" event of RemoteSettings). We still follow how Safe Browsing periodically checks whether there is a newer version of list. Note. This patch changes the flow comparing with how we usualy receive SafeBrowsing response from Shavar. In Shavar case, the list data response usually comes with "n:21600\ni:listname1\nu:redirectURL1\ni:listname2\nu:redirectURL2 ..." first. And then we fetch the data again from the redirectURL for each list. But in the current implementation, responses don't contain redirectURL anymore (since we already have the data). So the mocked response will contain all the data needed in one response. For example: "n:21600\ni:listname1\n:chunkdata1\ni:listname2\n:chunkdata2...". Differential Revision: https://phabricator.services.mozilla.com/D135989

Bug 1771382 - Adjust the Linux RDD sandbox to handle the nvidia driver being loaded but not used. r=gcp 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

Bug 1770905 - Allow GeckoMediaPlugin processes on Linux to be profiled if memfd_create is available. r=gcp,mstange,media-playback-reviewers,padenot 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

Bug 1770905 - Quietly reject `readlink` in the Linux GeckoMediaPlugin sandbox. r=gcp 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

Bug 1773043 - Remove flashblock from SafeBrowsing r=perftest-reviewers,gcp,sparky Depends on D149129 Differential Revision: https://phabricator.services.mozilla.com/D149130

Bug 1772142 - Fix the RDD sandbox to deal with Snap moving some config files. r=gcp In the Snap environment, some system config files aren't in their usual places, but rather in a subtree rooted at `$SNAP/gnome-platform`, which seems to also be `$SNAP_DESKTOP_RUNTIME`. This includes some subdirectories of `/usr/share` that we need for EGL to work. This could probably also have been fixed in the Snap packaging, given that [Mozilla's][] and [Ubuntu's][] specs both put `/usr/share/libdrm` back into its normal location, but for now it's easiest to adjust the sandbox, given that (I think?) anything under `$SNAP` is public information so we lose nothing by allowing read access. (See also bug 1732580.) [Mozilla's]: https://searchfox.org/mozilla-central/rev/973000acec0cbf7211e0fad89ca00c352aeb8384/taskcluster/docker/firefox-snap/firefox.snapcraft.yaml.in#50-52 [Ubuntu's]: https://git.launchpad.net/~mozilla-snaps/firefox-snap/+git/firefox-snap/tree/snapcraft.yaml?id=a24fb4a3f92d190299e4126ecc4132087c2aed3d#n85 Differential Revision: https://phabricator.services.mozilla.com/D148925

Bug 1772101 - Part 46: Use plain object for lazy getter in toolkit/components/url-classifier/. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D147987

Bug 1770523 - Return to not allowing X11 access in the RDD process. r=gcp 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

Bug 1770703 - Duplicated ioctl() case when building with MOZ_ASAN r=gcp Differential Revision: https://phabricator.services.mozilla.com/D147057

Bug 1769182 - Allow the RDD process to use EGL under X11 on Linux. r=gcp 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

Bug 1769182 - Factor out the X11/Mesa-related parts of Linux sandbox file policies. r=gcp 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

Bug 1769182 - Allow send/recv and sendto/recvfrom in the common Linux sandbox policy. r=gcp 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

Bug 1769182 - Factor out connect() brokering in the Linux sandbox policies. r=gcp 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

Bug 1769182 - Refactor seccomp-bpf sandbox policy constructors. r=gcp 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

Bug 1770126 - Make WindowsLocationProvider::Watch() not try to watch for events if already watching. r=gcp The second call would fail and thus fall back to MLS, but only null out mLocation (not unregister the existing listener), so Windows would think we're still using the location permission forever. Differential Revision: https://phabricator.services.mozilla.com/D146785

Bug 1770126 - Make WindowsLocationProvider::Startup() deal correctly with already-initialized instances. r=gcp We can call Startup() on an already-running instance, and that would cause us to not unregister notifications from a pre-existing ILocation instance, which seems likely to cause things like bug 1766770. Other location providers deal correctly with this. Differential Revision: https://phabricator.services.mozilla.com/D146783

Bug 1769309: Block hmpalert.dll v3.8.8.889 and earlier due to crashes with win32k lockdown. r=gcp The version from a fresh install from Sophos website is 3.8.19.923. Only blocking in child processes. Differential Revision: https://phabricator.services.mozilla.com/D146382

Bug 1769182 - Allow the RDD process to use EGL under X11 on Linux. r=gcp 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

Bug 1769182 - Factor out the X11/Mesa-related parts of Linux sandbox file policies. r=gcp 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

Bug 1769182 - Allow send/recv and sendto/recvfrom in the common Linux sandbox policy. r=gcp 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

Bug 1769182 - Factor out connect() brokering in the Linux sandbox policies. r=gcp 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

Bug 1769182 - Refactor seccomp-bpf sandbox policy constructors. r=gcp 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

Bug 1768800: Remove EARLY_BETA_OR_EARLIER guards for safaweb*.dll blocking. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D146048

Bug 1767993 p2: Remove EARLY_BETA_OR_EARLIER guards for qipcap*.dll blocking. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D146043

Bug 1767993: Block Forcepoint qipcap*.dll v7.7.819.1 and earlier for high crash rate. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D145957

Bug 1766029: Block safaweb* DLLs in child processes due to win32k lockdown crash. r=gcp The version is the last one for which we have seen crashes. Differential Revision: https://phabricator.services.mozilla.com/D145899

Bug 1768014 p2: Default to policy win32k lockdown status if in process check fails. r=gcp,cmartin Depends on D145872 Differential Revision: https://phabricator.services.mozilla.com/D145873

Bug 1768014 p1: Transfer mitigations to sandboxed child process. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D145872

Bug 1767999: Re-enable Win32k Lockdown by default. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D145618

Bug 1765750 - Part 2: Stop using global this in UrlClassifierListManager.jsm. r=gcp Depends on D144943 Differential Revision: https://phabricator.services.mozilla.com/D144944

Bug 1765750 - Part 1: Stop exposing the global this object in UrlClassifierLib.jsm. r=gcp Differential Revision: https://phabricator.services.mozilla.com/D144943

Bug 1766022: Add videocapturer* to the child process DLL blocklist. r=gcp This has been found to cause crashes when win32k lockdown is enabled. Differential Revision: https://phabricator.services.mozilla.com/D144459