This commit does:
- Sync files under security/sandbox/chromium/ with Chromium 81.0.4044.138
- Update files under security/sandbox/chromium-shim/
- Apply patches under security/sandbox/chromium-shim/patches/with_update/
- Apply a workaround for Clang's bug to compile filesystem_interception.cc
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Depends on D79558
Differential Revision: https://phabricator.services.mozilla.com/D79560
This commit updates files under security/sandbox/chromium-shim/patches/
to prepare our codebase for Chromium sandbox update. See patch files for
the details of each patch.
This also removes the following patches from with_update no longer needed.
1) update_chromium_linux_x86_syscalls.patch is included in
b4f3df4e77
2) ifdef_out_ApplyMitigationsToCurrentThread.patch cannot be used because
we use ApplyMitigationsToCurrentThread since the following commit.
4bed2eb502
3) mingw_base_win_get_caller.patch is included in
d8b73eb8f0
4) fix_incorrect_int_use_in_Kernel32BaseVersion.patch is fixed by
https://hg.mozilla.org/mozilla-central/rev/dc9d71fb3bac807a37dbfba35d609ac4ffff1980
5) revert_removal_of_AlterEnvironment_on_Windows.patch is altered by adding
environment_internal.h/cc as a different commit.
6) mingw_undefine_MemoryBarrier.patch is no longer needed as
base::subtle::MemoryBarrier was removed by
bdbaaf4e7e
7) public_siginfo_fields.patch is included in
6bd491daaf
Differential Revision: https://phabricator.services.mozilla.com/D79558
converts:
* security.sandbox.rdd.win32k-disable
* security.sandbox.gmp.win32k-disable
I'm assuming the pattern established by the other, newer, win32k StaticPrefs can
be followed here, and the xpcom checks aren't needed.
Differential Revision: https://phabricator.services.mozilla.com/D78933
Content processes allow a restricted subset of F_{GET,SET}{FD,FL} that
prevents setting unknown or known-unsafe flags, which was copied to the
socket process policy; this patch moves it to the common policy and
removes RDD's copy of GMP's override.
The immediate reason for this is DMD using F_GETFL via fdopen to use a
file descriptor passed over IPC, but in general this should be safe and
it's a reasonable thing to expect to be able to use.
Differential Revision: https://phabricator.services.mozilla.com/D77379
When the browser process starts a sandbox process, we copy the executable's IAT
for ntdll.dll into the new process to prevent DLL injection via IAT tampering as
the launcher process does. However, if IAT has been modified by a module injected
via `SetWindowHookEx`, the browser process cannot copy IAT because a modified IAT
is invalid in a different process, failing to start any sandbox processes.
The proposed fix is to cache IAT before COM initialization which may load
modules via `SetWindowHookEx` for the first time in the process.
Differential Revision: https://phabricator.services.mozilla.com/D73303
If a third-party application modifies IAT of ntdll.dll in the browser process
after process launch, the browser process fails to launch a sandbox process,
resulting in a situation where a window is opened without any functionality.
This patch is to mitigate that situation by disabling the launcher process
when the browser process fails to launch a sandbox process.
Differential Revision: https://phabricator.services.mozilla.com/D70873
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
When the GPU sandbox is enabled, access to most of the filesystem is blocked.
The GPU process uses a directory, "%profiledir%/shader-cache", to cache
compiled shared for performance reasons. Not allowing access to that directory
results in a HUGE performance backslide when the sandbox is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D67893
--HG--
extra : moz-landing-system : lando
Add rule to allow content processes to duplicate named pipes to other child
processes. This is why SetLockdownDefaultDacl wasn't working before because it
broke the local handle duplication.
This also reverts the change that was using USER_LIMITED from the start of the
process because that breaks DLL loading when installed somewhere that relies on
the user's own SID for access.
Differential Revision: https://phabricator.services.mozilla.com/D68850
--HG--
extra : moz-landing-system : lando
We've had some bugs where the sandboxed child process and/or the chroot
helper process deadlocks during launch, often reported by end users,
and it's confusing to have the mysterious hanging task inherit the name
of the launching thread; this patch fixes that by giving them more
informative names.
`prctl(PR_SET_NAME, ...)` is used directly, instead of via one of our
wrappers for it, to avoid the possibility of async signal unsafe
operations.
This doesn't name the pre-exec child process in the cases where regular
`fork()` is used, but as far as I know we haven't had any bugs (yet?)
where that would matter.
Differential Revision: https://phabricator.services.mozilla.com/D68134
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
When the launcher process is enabled, we run `RestoreImportDirectory` twice as
below. This patch removes the 1st one.
1st call:
xul!mozilla::SandboxBroker::LaunchApp
--> xul!mozilla::RestoreImportDirectory
2nd call:
xul!mozilla::SandboxBroker::LaunchApp
--> firefox!mozilla::InitializeDllBlocklistOOP
--> firefox!mozilla::InitializeDllBlocklistOOPInternal
--> firefox!mozilla::RestoreImportDirectory
To handle the case where the launcher process is disabled, we need to call
`RestoreImportDirectory` from `InitializeDllBlocklistOOP` if the browser
process is not bootstrapped.
Differential Revision: https://phabricator.services.mozilla.com/D62853
--HG--
extra : moz-landing-system : lando
The special handling of PR_SET_NO_NEW_PRIVS can't be overridden with
Allow(); otherwise every thread in the process will repeatedly apply
copies of the policy to itself until it reaches whatever limits the
kernel imposes, and then we crash so we don't continue execution
seemingly unsandboxed. (See also bug 1257361.)
The prctl policy for the socket process is still allow-all after this
patch; it just prevents crashing the socket process on startup on
kernels before 3.17 (which don't support applying the policy atomically
to all threads).
This patch also adds a comment to try to document this failure mode.
Differential Revision: https://phabricator.services.mozilla.com/D66523
--HG--
extra : moz-landing-system : lando
This adds AddRestrictingRandomSid feature, which fixes our issues with
SetLockdownDefaultDacl, apart from when we are running from a network drive.
Differential Revision: https://phabricator.services.mozilla.com/D66610
--HG--
extra : moz-landing-system : lando
This adds AddRestrictingRandomSid feature, which fixes our issues with
SetLockdownDefaultDacl, apart from when we are running from a network drive.
Differential Revision: https://phabricator.services.mozilla.com/D66610
--HG--
extra : moz-landing-system : lando
Add, but don't enable, a sandbox policy to be used with the socket process.
A follow-up fix (bug 1611288) will change the socket process code to use the
sandbox. The macOS socket sandbox is similar to the utility sandbox (only
used for the RDD process), with additions to allow networking I/O, access to
files for DNS resolution, access to certificate stores, and notifications about
network configuration changes.
Differential Revision: https://phabricator.services.mozilla.com/D64682
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
Cherry-picking the following commits from Chromium to keep file_version_info_win.cpp
up-to-date.
1. Use StringPiece rather than std::string for Version parsing.
15a9d1733f
2. [Cleanup] Un-const the result of base::Version::GetString()
fde745d058
3. Export Windows file version as base::Version
e93de3a37d
4. Tidy FileVersionInfoWin.
4bb23ded3a
Differential Revision: https://phabricator.services.mozilla.com/D65802
Depends on D65744
This patch partially implements `FileVersionInfoWin` and `base::FilePath` class of
Chromium sandbox so that a coming patch can use `base::win::OSInfo::Kernel32BaseVersion()`.
Differential Revision: https://phabricator.services.mozilla.com/D65744