This patch enables pre-spawn CIG in the RDD process.
If CIG prevents a module in the executable's Import Directory Table, Windows totally
fails to launch a process. So we add a policy rule of `SUBSYS_SIGNED_BINARY` for
all files under the directory containing the executable such as mozglue.dll, and
modules injected via Import Directory Table. The latter ones will be blocked by our
blocklist with `REDIRECT_TO_NOOP_ENTRYPOINT` (bug 1659438).
Differential Revision: https://phabricator.services.mozilla.com/D96933
Chromium's Linux sandboxing code needs some architecture-specific files
for ARM and ARM64 that we don't currently include in our partial import.
These are copied from Chromium tag 81.0.4044.138 (matching the latest
import of the rest of security/sandbox/chromium) without changes.
Differential Revision: https://phabricator.services.mozilla.com/D89994
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/
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Differential Revision: https://phabricator.services.mozilla.com/D79560
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 *_interception.cc
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Differential Revision: https://phabricator.services.mozilla.com/D79560
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 *_interception.cc
- Add mozilla::AddWin32kLockdownPolicy to apply MITIGATION_WIN32K_DISABLE before SUBSYS_WIN32K_LOCKDOWN
Differential Revision: https://phabricator.services.mozilla.com/D79560
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 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
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
Upstream patch:
6bd491daaf%5E%21/#F0
_sifields is a glibc-internal field, and is not available on musl
libc. Instead, use the public-facing fields si_call_addr, si_syscall,
and si_arch, if they are available.
Differential Revision: https://phabricator.services.mozilla.com/D61051
--HG--
extra : moz-landing-system : lando
Fix:
/var/lib/jenkins/workspace/firefox-clang-lld-last/security/sandbox/chromium/base/time/time.h:796:18: error: implicit conversion from 'long' to 'double' changes value from 922337203
return value > std::numeric_limits<int64_t>::max()
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Upstream code is very different now (uses some saturated_cast):
https://chromium.googlesource.com/chromium/src/base/+/master/time/time.h#846
Differential Revision: https://phabricator.services.mozilla.com/D43786
--HG--
extra : moz-landing-system : lando
This is because we are hitting it frequently during PolicyBase::OnJobEmpty and
currently we can't work out how this can happen.
Differential Revision: https://phabricator.services.mozilla.com/D38090
--HG--
extra : moz-landing-system : lando
This updates security/sandbox/chromium/ files to chromium commit 84108231f6e6e0772fb9a4643679ce76aa771e67.
Existing and new patches applied from security/sandbox/chromium-shim/patches/with_update/ to give a compiling and mostly working browser.
See patch files for additional commit comments.
--HG--
rename : security/sandbox/chromium-shim/base/debug/debugging_flags.h => security/sandbox/chromium-shim/base/debug/debugging_buildflags.h
rename : security/sandbox/chromium-shim/base/win/base_features.h => security/sandbox/chromium-shim/base/win/base_win_buildflags.h
There's a bug in ole32.dll on arm64 versions of Windows prior to 1809, that crashes our content processes if we enable CFG. We've reported the issue, but even if it gets fixed, we can't assume users will have the update.
This patch uses process mitigation policy flags to disable CFG on arm64 before 1809. Based on testing, we only need to do this in the sandbox for child processes, and it's not strictly necessary for the launcher stub to set the flag on the main process. But I've included that anyway as a guard against some yet-undiscovered scenario that might hit the issue and make the browser unusable.
The effects of this patch won't be visible until we actually enable CFG in a subsequent landing.
Differential Revision: https://phabricator.services.mozilla.com/D29474
--HG--
extra : moz-landing-system : lando
There's a bug in ole32.dll on arm64 versions of Windows prior to 1809, that crashes our content processes if we enable CFG. We've reported the issue, but even if it gets fixed, we can't assume users will have the update.
This patch uses process mitigation policy flags to disable CFG on arm64 before 1809. Based on testing, we only need to do this in the sandbox for child processes, and it's not strictly necessary for the launcher stub to set the flag on the main process. But I've included that anyway as a guard against some yet-undiscovered scenario that might hit the issue and make the browser unusable.
The effects of this patch won't be visible until we actually enable CFG in a subsequent landing.
Differential Revision: https://phabricator.services.mozilla.com/D29474
--HG--
extra : moz-landing-system : lando
In Bug 1462100 we started casting to void* because mingw doesn't do
automatic conversions like MSVC does. In Bug 1498695 I backed out that
change because I (mistakenly) thought it wasn't necessary for mingw-clang
when in actuality, I simply wasn't hitting the code path due to
SANDBOX_EXPORTS being defined.
Since we want to _not_ define SANDBOX_EXPORTS I need to put the original
patch back in place.
--HG--
extra : amend_source : a26eec746e7881fa88b963c8dd3c1fa900b6a8b6
mingw-clang, when using SEH exceptions, compile these fine but don't unwind
them properly. When using sj/lj exceptions it can't compile them at all.
--HG--
extra : histedit_source : 4bda121d4d60ab6e7cf51a3d4287261c81904fe2
I'm not adding a patch to security/sandbox/chromium-shim/patches for this,
because we need to get this fixed ASAP, certainly before we take another update.
This function is a technique to name a thread for debugging purposes,
and it always throws an exception (and then continues). On MinGW
we don't want it to throw an exception, so we do nothing.
This means on MinGW we won't get nice thread naming during debugging,
but we'll limp along.
MozReview-Commit-ID: JRKY4wp7sdu
--HG--
extra : rebase_source : 439205d83167dcde5306f9899244e7d336116111
This reverts 6e41201152dd (Bug 1431621) which compiled but did not link.
It also fixes the original issue by removing the stray \ at the end of the
line that was causing the error.
MozReview-Commit-ID: LgaxYK3EOwR
--HG--
extra : rebase_source : 7de3b5126417ea99ff7fee3a809e556b5a2de4a6
error: invalid conversion from 'FARPROC {aka int (__attribute__((__stdcall__)) *)()}' to 'void*' [-fpermissive]
According to http://stackoverflow.com/questions/13958081/, msvc does the fixup
MozReview-Commit-ID: HTghe9uL0EP
--HG--
extra : rebase_source : b083b9247aa07ba58c23b3b3a2e5b19c7393dafb
Toshihito Kikuchi
Bob Owen
Jed Davis
Dorel Luca
Bogdan Tara
Narcis Beleuzu
Michael Forney
Sylvestre Ledru
Gian-Carlo Pascutto
Tom Ritter
David Major
Coroiu Cristina