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
Initialize in advance all security services whose initialization on background thread could cause a deadlock.
--HG--
extra : rebase_source : 399f9acf736f9a06665d45a71b354076c1b85fa6
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 : 43c52a1169d6f510c3dc83143736b9be7ed7141d
When the user performs a PKCS#11 logout, we need to cancel all in-progress
network connections. Before this patch, PSM would track all the sockets it
created to implement this feature. However, bug 1411316 added the ability to
cancel these connections by sending the notification
"net:cancel-all-connections". This patch removes the now-unnecessary tracking
machinery in favor of delegating this to necko.
MozReview-Commit-ID: 7IzC14bH2R4
--HG--
extra : rebase_source : 57ff2121a2395cb2b012785ec3a11f75d923e675
PK11PasswordPromptRunnable::RunOnTargetThread instantiates nsINSSComponent and
calls GetPIPNSSBundleString/PIPBundleFormatStringFromName to get some localized
strings. Since that runs on the main thread, we can call the helpers in
nsNSSCertHelper instead.
MozReview-Commit-ID: GsHoGDKBKdB
--HG--
extra : rebase_source : 7c18498ad0d01ab01f6e7d8c3d2ccdb1d6e20734
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : source : e2beba7e6875120ebbbcadf24bcbcb5b86411a94
extra : amend_source : 11f07a27431cd468511f0bd45afe36150c6e342c
Remove the headers included for "backwards compatibility" and just include them
where required.
--HG--
extra : rebase_source : 03e703a81ed4b80f4f116ff36d8787464ce5acba
Adapted from https://wiki.mozilla.org/SecurityEngineering/NSS_Startup_and_Shutdown_in_Gecko :
Properly implementing the coordinated shutdown of NSS has, to date, proved
intractable. For architectural reasons and due to the significant complexity
involved, the NSS resource tracking and shutdown infrastructure has been an
ongoing source of crashes and hangs in Firefox. To that end, we have been
exploring the possibility of not shutting down NSS at all. For this to work, we
have had to address a number of potential concerns.
Certificate and key database corruption: In theory, if Firefox were to exit
without coordinating with NSS, data stored in the certificate and key databases
(backed by BerkeleyDB) could be lost. To mitigate this, we have migrated to
using the sqlite-backed implementation. The databases are now journaled, and
short of a bug in sqlite, we do not anticipate data loss due to database
corruption.
PKCS#11 devices: In theory, if Firefox were to exit without coordinating with
NSS and thus any attached PKCS#11 devices, data could be lost on these devices.
However, it is our understanding that these devices must be robust against
unexpected physical removal. Uncoordinated shutdown should present no worse a
risk to user data.
FIPS 140-2 mode: While Mozilla does not ship a version of Firefox that supports
FIPS mode out of the box, Red Hat does. It is our understanding that clearing
key material is a requirement of FIPS and that not shutting down NSS may pose a
problem for this requirement. Red Hat's FIPS 140-2 Security Policy[0] specifies
that the application (i.e. Firefox) using the module (i.e. NSS) is responsible
for zeroization of key material. More specifically, it says "All plaintext
secret and private keys must be zeroized when the Module is shut down (with a
FC_Finalize call), reinitialized (with a FC_InitToken call), or when the session
is closed (with a FC_CloseSession or FC_CloseAllSessions call)." Thus, if
Firefox never shuts down NSS, this requirement is trivially met.
Leak detection: By not shutting down NSS, technically we leak some allocated
memory until shutdown. This could cause problems if our test infrastructure
detected and reported these leaks. However, it appears not to (which itself is
somewhat concerning). In any case, we will have to deal with this if and when we
can detect these leaks.
Given that these concerns all have at least a preliminary answer, we will move
forward with attempting to not shut down NSS in Firefox. This may expose
unexpected issues that may lead to a reassessment of the situation, so this will
be on a trial basis only in Nightly.
[0] https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3070.pdf
MozReview-Commit-ID: LjgEl1UZqkC
--HG--
extra : rebase_source : 99bf715f7f6566ec92ca763eefdbd8d2f69d2ba2
extra : amend_source : d4177cc87f54fccbd49312feef7e29b77bf01432