This patch also adds the capitalization patch file to the chromium patches
MozReview-Commit-ID: BzAkEtCKAi4
--HG--
extra : rebase_source : 8f24d2b855e721f354f12b0d3fca5783cc66702e
Enable sandbox read access extensions to allow content processes
to access fonts stored in non-standard locations without whitelisting
hardcoded directories. This is needed for configurations with third
party font managers that store fonts in their own directories or
user-specified directories.
Now that font access is not dependent on the filename extension
such as .otf and .ttf, remove the relevent tests.
MozReview-Commit-ID: 8hSMrocGwIm
--HG--
extra : rebase_source : b757480398e3f0d9720ab845e9f10fb70a794d77
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
This also removes an assertion that was failing under external sandboxes
that deny unshare() even when it's a no-op.
MozReview-Commit-ID: KBEPJyDGU7M
--HG--
extra : rebase_source : 411a51d7707e506ca8cbe49553ada1de02f7c76b
MinGW doesn't recognize the ui64 prefix, but uLL is equivalent.
MozReview-Commit-ID: Do3hikKzxY7
--HG--
extra : rebase_source : 501e958ce50e95ae1171acc10fb07c28834195d2
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
This also moves those parts of the policy factory out of the constructor,
because the pref service isn't initialized yet at that point.
MozReview-Commit-ID: 6wbq4MHu1GJ
The end goal is to allow the seccomp-bpf policy to vary based on the
content sandbox level.
Rather than add yet another parameter to SetContentProcessSandbox to
pass down the sandbox level, this collects the values that have to be
computed in libxul into a struct, and moves the code that computes it so
it's not cluttering up ContentChild.
MozReview-Commit-ID: L0dyQwHQKhc
On MinGW, these typedefs are the same, and mingw complains about duplicate instantiations.
Rather than use -fpermissive, just comment out the second instantiation.
MozReview-Commit-ID: 5prsrStgwKY
--HG--
extra : rebase_source : 843340df6e2ce835794b4f370f846b249babf93c
Note that MinGW defines it without __builtin_extract_return_addr which
means we're dropping that, but the gcc documentation indicates that
shouldn't be an issue. It is needed when a fixup is necessary:
> For example, on the 31-bit S/390 platform the highest bit has to
> be masked out, or on SPARC platforms an offset has to be added for
> the true next instruction to be executed.
MozReview-Commit-ID: 4D5bIT9Fei4
--HG--
extra : rebase_source : 3f959d72ab3a756e0d636b5eaaf3e883042e9865
This is a small piece of cleanup that turned out to not be strictly
necessary for the rest of this, so I've made it a separate commit.
Sandbox-related launch adjustments (currently, interposing libc
functions and providing a file descriptor for the syscall reporter)
are no longer applied to processes that won't be sandboxed. The
MOZ_SANDBOXED environment variable communicates this to the child
process, which allows SandboxEarlyInit to be skipped in that case as
well. The idea is that disabling sandboxing for a process type, as part
of troubleshooting, should disable everything sandbox-related.
As a side-effect, this also skips some very minor but unnecessary
overhead for NPAPI process startup.
MozReview-Commit-ID: D0KxsRIIRN
--HG--
extra : rebase_source : 89836bea80d0a171324a8e3ff15c6b8e2a163ea9
Before this patch, mozilla::pkix gtests would generate a public/private key pair
and stash it in a global variable. Since this wasn't part of XPCOM nor tracked
by the PSM/NSS shutdown machinery, it wouldn't get released at the appropriate
time. The solution to this is to generate the key and then essentially export it
as data, so no NSS objects are held alive. Since NSS considers private keys
stored in the persistent database sensitive and won't export them in the clear,
we "encrypt" the key material with an empty password so we can import it when
necessary. (While the gtests don't use persistent keys, the test utilties in the
gtests are also used by some xpcshell tests that do use persistent keys, hence
the need to encrypt the key material.)
--HG--
extra : rebase_source : df10c25a462a3ba0396f5ba4a43a52fb924548ff
extra : amend_source : d95722891e49a99c471046cd9c758e914a02838e
Historically, PSM has handled tracking NSS resources, releasing them, and
shutting down NSS in a coordinated manner (i.e. preventing races,
use-after-frees, etc.). This approach has proved intractable. This patch
introduces a new approach: have XPCOM shut down NSS after all threads have been
joined and the component manager has been shut down (and so there shouldn't be
any XPCOM objects holding NSS resources).
Note that this patch only attempts to determine if this approach will work. If
it does, we will have to go through alter and remove the remnants of the old
approach (i.e. nsNSSShutDownPreventionLock and related machinery). This will be
done in bug 1421084.
MozReview-Commit-ID: LjgEl1UZqkC
--HG--
extra : rebase_source : 2182e60d04e89a91278d5ee91610f8f37d99a9c9
This is a JS style cleanup; it changes all relevant `var` decls to `let`, and
also moves the `gSSService` up to the top where globals should go.
MozReview-Commit-ID: 2yycCum6mRC
--HG--
extra : rebase_source : 63563665d4d9991e181562acbd7e53f66e4c13b9
The Chromium HSTS Preload list now includes a "policy" field that we can use
to filter and force some HSTS entries. This patch unconditionally accepts list
entries with the "google" or "public-suffix-requested" policies, and tests all
others via the existing connect-and-check (with failback tolerance) strategy.
In comment #0 of this bug [2], Lucas recommends we also filter the "all others"
to be the "bulk" entries. This patch does not do that to be conservative and
avoid de-listing sites at this time. We'll probably want a follow-on to
evaluate and potentially do that.
The patch also:
* renames `getHSTSStatuses` to `probeHSTSStatuses` to indicate more clearly that
it's an active network load.
* Sets an X-Automated-Tool: https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js
[1] https://github.com/chromium/hstspreload.org/wiki/Preload-List-Processes#manual-hsts-entries
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1418112#c0
MozReview-Commit-ID: 2r1QYXtDfjw
--HG--
extra : rebase_source : 3110915d15ffe9ea1916a6bd4957911bac0493fb
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
This reworks the certificate-fetching portion of the add certificate exception
dialog so as to not require a nsIBadCertListener2 implementation, which is
deprecated. The solution is simple: use the onerror/onload callbacks on the
XMLHttpRequest object to grab the appropriate information.
MozReview-Commit-ID: IjNrNfYA28P
--HG--
extra : rebase_source : 4a09b2eaf81d675444553156a0e098be54703115
Previously, adding a permanent certificate error override would depend on
successfully importing the server's certificate into the user's certificate
database. Consequently, if the user's database were in read-only mode (or if the
database couldn't be created due to code page issues on Windows), this would
prevent adding new certificate error overrides. It turns out this isn't even
necessary, because the implementation relies on the stored hash of the
certificate rather than the certificate itself. The stored certificate is only
for display purposes (and there's a fallback if the certificate can't be
stored).
There are remaining issues with non-ASCII characters in 8.3 paths on Windows
when the code page isn't western, but this is a larger issue that must be
addressed in other layers (i.e. NSS/NSPR).
MozReview-Commit-ID: KEzjxtAoeb4
--HG--
rename : security/manager/ssl/tests/unit/test_cert_overrides.js => security/manager/ssl/tests/unit/test_cert_overrides_read_only.js
extra : rebase_source : b41e863d8c85d80335dd56c8f5765b19b1de4e0c
Also changes gSeccompTsyncBroadcastSignum to an atomic, in case these
wrappers race with starting the sandbox, and optimizes the wrappers
slightly by avoiding unnecessary copying of signal sets or sigactions.
Tested by manaully LD_PRELOADing libmozsandbox in the parent process,
because it already has a few signal handlers with block-by-default
masks.
MozReview-Commit-ID: CiHsA6rOCrQ
--HG--
extra : rebase_source : 176c156116a44fb8dff3a5f421499b7e61175047
This helps with getting the tests that are running out of /tmp
to pass, who get confused if their paths change underneath them.
It's also a bit faster.
MozReview-Commit-ID: CWtngVNhA0t
--HG--
extra : rebase_source : ec91614556601e32f2604c3fb9f7d08156f834f3
This may be required if people have @import in their userContent.css, and
in any case our tests check for this.
MozReview-Commit-ID: 8uJcWiC2rli
--HG--
extra : rebase_source : 3384cb599a6d7b1aeba64e552ec4778ddab03f39
Historically, PSM has handled tracking NSS resources, releasing them, and
shutting down NSS in a coordinated manner (i.e. preventing races,
use-after-frees, etc.). This approach has proved intractable. This patch
introduces a new approach: have XPCOM shut down NSS after all threads have been
joined and the component manager has been shut down (and so there shouldn't be
any XPCOM objects holding NSS resources).
Note that this patch only attempts to determine if this approach will work. If
it does, we will have to go through alter and remove the remnants of the old
approach (i.e. nsNSSShutDownPreventionLock and related machinery). This will be
done in bug 1421084.
MozReview-Commit-ID: LjgEl1UZqkC
--HG--
extra : rebase_source : 95050b060a93223c6f2fce90f44e563fa6ed4fa2
