This patch does a few things:
1) It removes the symantecRoot and symantec_affected certs from build/pgo/certs'
DB.
2) It upgrades that DB from the old format to SQLite (and this 8/3 to 9/4).
3) It adds a new cert "imminently_distrusted" to that DB for the bc test.
4) It changes the Subject of the immient distrust test to only have the CN
field: this is because certutil reorders C to come after CN, and just like
with the real Symantec certs, I had put C first. So rather than deal with
importing the end entity for the pgo tests, I decided to just make things
simple and change the tested subject.
5) Finally, it re-enables the test that was disabled in Bug 1434300.
MozReview-Commit-ID: Bt2RKyInJje
--HG--
rename : build/pgo/certs/cert8.db => build/pgo/certs/cert9.db
rename : build/pgo/certs/key3.db => build/pgo/certs/key4.db
extra : rebase_source : efceb67ae16f0af617bbd8bec201d52eee0f467d
This is the test originally from Bug 1434300 that was pulled due to
Bug 1433015.
MozReview-Commit-ID: IEPCRVdS2v4
--HG--
extra : rebase_source : 843222f36b9fffe73cdf02aebb3f263897a943de
Also covers fchownat() and attempts to be ready for newer archs like ARM64.
Bonus fix: extend bug 1354731 (mknod) fix to cover mknodat so this part
of the policy isn't glaringly inconsistent about "at" syscalls.
Tested locally by attaching gdb and injecting syscalls.
MozReview-Commit-ID: CCOk0jZVoG4
--HG--
extra : rebase_source : 1d0cafd9d91586eaec0233ff15b3bbb1ef7485f0
This adds the 4 digicert CAs to our whitelist as specified in Google's details
on the Chromium version of this plan [1].
[1] c022914eb2/net/data/ssl/symantec/README.md
MozReview-Commit-ID: BR7t1UheKeS
--HG--
rename : security/certverifier/TrustOverride-AppleGoogleData.inc => security/certverifier/TrustOverride-AppleGoogleDigiCertData.inc
extra : rebase_source : 406e42e805b3778ccce7ee85b18d5dea93e32b95
Because of the DigiCert-controlled sub-CAs and managed-CAs identified as also
needing to be whitelisted [1], and that those CAs are using an increasing number
of certificates all with different Subjects (but identical public keys) [2][3],
we will have to whitelist on SPKI rather than subject DN.
This makes the security/manager/ssl/tests/unit/test_symantec_apple_google.js
integration test different, as it now uses a real Google certificate that is
in the whitelist with only a cert verification rather than a full connection
test.
This patch does not add the DigiCert SPKIs to the list; I will do that in its
own patch.
[1] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/README.md
[2] https://chromium-review.googlesource.com/c/chromium/src/+/916730
[3] https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee
MozReview-Commit-ID: 4qVeogDbSb
--HG--
extra : rebase_source : abbdd432b190d059a3b2ceeccf89b85a12c214dd
This modifies crtshToDNStruct.py to be able to produce SPKI or DN-based lists,
and adds a SPKI-search method to TrustOverrideUtils.h.
This also regenerates the TrustOverride files to use the new script.
MozReview-Commit-ID: BhMoJbYXs7Y
--HG--
rename : security/manager/tools/crtshToDNStruct/crtshToDNStruct.py => security/manager/tools/crtshToIdentifyingStruct/crtshToIdentifyingStruct.py
rename : security/manager/tools/crtshToDNStruct/requirements.txt => security/manager/tools/crtshToIdentifyingStruct/requirements.txt
extra : rebase_source : 9ae4999ceea2d4092119fe81b787c4d66a5e17b1
The algorithm from https://hg.mozilla.org/mozilla-central/rev/595e27212723
(Bug 1409259) is adapted in this patch from nsNSSCallbacks into the TrustDomain
decisions.
This patch does not change the algorithm to use SPKI matching, nor add the
additional whitelisted intermediates from DigiCert; that will be done in a
separate commit.
This patch also does not update the pre-existing browser chrome test.
MozReview-Commit-ID: 1PdCAqo71bI
--HG--
extra : rebase_source : f1c6d00e16682f9303b8b2bfdf1fe5773c515ac5
This patch does a few things:
1) It adds a permament test mechanism for the "imminent distrust" trust status
in nsNSSCallbacks: a simple xpcshell test to exercise a clause in the imminent
distrust logic in nsNSSCallbacks' IsCertificateDistrustImminent method.
2) This test removes test_symantec_apple_google_unaffected.js as its
functionality is rolled into the new test_imminent_distrust.js.
3) It updates the Symantec imminent distrust warning algorithm to remove the
validity date exception; this warns of the upcoming distrust for those affected
certs in Firefox 63.
This patch does not attempt to edit the browser chrome test that checks the
console; that is a subsequent patch.
MozReview-Commit-ID: 1HyVLfmEOP7
--HG--
extra : rebase_source : 3955e3dcd9a21421105d97bd65d3965041de9b8c
Adds MITIGATION_IMAGE_LOAD_NO_REMOTE and MITIGATION_IMAGE_LOAD_NO_LOW_LABEL to the plugin process if we aren't running from a networked drive. The same condition applies to these mitigations in the content process.
--HG--
extra : rebase_source : b61f91f3e56f6b4930a03331b7791a9173857518
Enables new process mitigations that have been included from Chromium upstream.
--HG--
extra : rebase_source : 8997bef9c6a6c660b39e68ebfabf90f4de162bca
This warning is triggered by the use of alignas() in js/public/RootingAPI.h.
Now that GeckoProfiler.h includes RootingAPI.h, this warning is encountered
when building security/certverifier because GeckoProfiler.h is already being
included transitively, through this inclusion path:
CertVerifier.cpp -> CertVerifier.h -> Telemetry.h -> StartupTimeline.h -> GeckoProfiler.h
However, this explanation is not entirely satisfactory, because there seems to
be an existing inclusion path for RootingAPI.h already:
CertVerifier.cpp -> CertVerifier.h -> BasePrincipal.h -> OriginAttributes.h
-> ChromeUtils.h -> ChromeUtilsBinding.h -> RootingAPI.h
So I'm not quite sure why this problem is only starting to happen now.
MozReview-Commit-ID: AFuXpTjdPsi
--HG--
extra : rebase_source : 60f74c8655d15fbc6acbf0ce8a2f208e198e231e
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This fixes a mistake in bug 1401062: the termination signal was omitted,
so it's 0, and if it isn't exactly SIGCHLD, then a tracer/debugger will
receive PTRACE_EVENT_CLONE rather than PTRACE_EVENT_FORK. This causes
GDB to see the child process as a thread instead of a separate process,
and it becomes very confused after the process calls execve().
MozReview-Commit-ID: Baf2RFHVWRU
--HG--
extra : rebase_source : 50839967fc766bb9db123fe1af99a88495f8421b
This commit reworks PublicKeyPinningService::ChainHasValidPins and
PublicKeyPinningService::EvalChain to use nsNSSCertList directly. It also
updates nsSiteSecurityService::ProcessPKPHeader. This will be made more
efficient in Bug 1406854, where the call to VerifySSLServerCert gets replaced
with one to GetSucceededCertChain. (Such a change is premeature now because
before Bug 731478 lands this would lead to a session resumption regression
causing pins to not be set properly, which is triggered repeatedly in the
xpcshell tests.)
MozReview-Commit-ID: 1l186n1lXLH
--HG--
extra : rebase_source : 88e40bbf41b324ece762abfa84a758380102e199
extra : histedit_source : addcddf253c2901a25b29f65046908f52df61345
This change is to use the higher-level structure nsNSSCertList when checking
IsChainValid so that we can use the more powerful (and tested) methods of that
object instead of the ad-hoc iterators.
This will also permit the Symantec Distrust code in Bug 1434300 to use these
methods, which keeps the code the same from the earlier Bug 1409259.
MozReview-Commit-ID: B5KmDa1JLE
--HG--
extra : rebase_source : 397d3ef7189eb6f81a1ceaf920464d9e842a8981
extra : histedit_source : 26b22257cb5fcc3389630dd0a1aba24095c46158
This adds another utility method to nsNSSCertList to perform CERT_LIST_TAIL on
the underlying certificate list and return the last entry -- e.g., the root.
This is a convenience method to let other parts of the certificate verifier
continue to work with the higher-level nsNSSCertificate objects instead of
having to convert them.
MozReview-Commit-ID: EEi9L5Iepc6
--HG--
extra : rebase_source : 2836767a7186f65debf338f8d1f2a981636ed29b
extra : histedit_source : 5b87ec6c522ac1b84d91052e21184f3c03d9ea52
This is part of the work to remove XUL overlays. All of these overlays are
used only once and do not need to be in their own overlay files.
MozReview-Commit-ID: Ecwq2UN52o9
--HG--
extra : rebase_source : 5a9692c7d9965940847ae1d488d1b94a2abf66c7
This replaces the globals for whether socket calls (and ipc(2) calls, but
we never used that) have real arguments with a parameter, which in hindsight
should have been done in bug 1273852, which is when we started handling
both socketcall(2) and separate socket calls in the same policy. This
allows handling the two cases differently.
MozReview-Commit-ID: 1pfckmCpJlW
--HG--
extra : rebase_source : 4b8459f01e8748fea95cbcb6eeb689f01417ca5b
There are a few things that use SysV IPC, which we discovered the last
time we tried to do this, which need to be accomodated:
1. The ALSA dmix plugin; if the build has ALSA support (off by default)
and if audio remoting is disabled, SysV IPC is allowed.
2. ATI/AMD's old proprietary graphics driver (fglrx), which is obsolete
and doesn't support newer hardware, but still has users; if it's
detected, SysV IPC is allowed.
3. Graphics libraries trying to use the MIT-SHM extension; this is
already turned off for other reasons (see bug 1271100), but that shim
seems to not load early enough in some cases, so it's copied into
libmozsandbox, which is preloaded before anything else in LD_PRELOAD.
Also, msgget is now blocked in all cases; the only case it was known
to be used involved ESET antivirus, which is now handled specially
(bug 1362601). In any case, the seccomp-bpf policy has never allowed
actually *using* message queues, so creating them is not very useful.
MozReview-Commit-ID: 5bOOQcXFd9U
--HG--
extra : rebase_source : ea79c0a7e31f58f056be15b551c57dde974dfae2
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
ca.pem is used to sign certificates that are either verified at time 2016-08-25
or time "now", with the earliest such certificate having a notBefore of
2015-07-24. As such, ca.pem.certspec needs to have a notBefore time that is no
later than 2015-07-24, but be valid for a reasonably long time.
Therefore, ca.pem.certspec is changed so the cert has a notBefore of 2015-01-01,
and is valid for 20 years.
ee-int-nsSGC-*.pem are verified at time 2016-08-25, and so need to be valid
at that time.
Therefore, the ee-int-nsSGC-*.pem.certspec files are changed so the
corresponding certs have validity periods that match their intermediates.
MozReview-Commit-ID: duOnvGGcuD
--HG--
extra : amend_source : 307c9d95b617560a547081ff8924d05ec2f2d2a8
For this, I've uncommented the relevant bits in moz.build files, then:
./mach build security/manager
for dir in $(rg GeneratedTestCertificate | grep security | cut -d : -f 1); do
cp obj-x86_64-pc-linux-gnu/$(dirname $dir)/*.pem $(dirname $dir);
done
And same with GeneratedTestKey / *.key
MozReview-Commit-ID: C2bkSo6YYCU
--HG--
extra : amend_source : b59d21b695544a1a4b6c45ba9c00c40f8ceb0f1a
This is part of the work to remove XUL overlays. All of these overlays are
used only once and do not need to be in their own overlay files.
MozReview-Commit-ID: 9NBBTg5KHxb
--HG--
extra : rebase_source : 675a5baa91b93eeb7253ad5773cb76e7db6be4fd
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
In bug 1406856 the failedCertChain property of nsITransportSecurityInfo was
changed to hold the built certificate chain out parameter from the call to
CertVerifier::VerifySSLServerCert. However, this was incorrect for two reasons:
a) failedCertChain is supposed to be the peer cert chain delivered by the server
in the TLS handshake and
b) if VerifySSLServerCert returns a failing result, the out parameter is not
guaranteed to hold any meaningful information, and must not be used.
This patch sets failedCertChain to the appropriate value.
MozReview-Commit-ID: BEXs5XH9SpK
--HG--
extra : rebase_source : f50ea725ccb67408ab1ce33cd76d3956ebd10e29
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
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 : 1be7a99cd3640d15ddecd1c050d19d1b30e5202d
extra : histedit_source : 5787bfe610504356a04819039469083adf2ce77c
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 : a93dfc2c62d3ac35dece87e4b4596cde761de207
extra : histedit_source : 455e6a79527226f398a861a72c1cfdef2c1761df
This is turned off if the X11 server is remote -- including TCP to
localhost -- because otherwise it would be blocked. Note that ssh X
forwarding presents a TCP-only server.
The Nightly default for the force-namespace hidden pref is changed to
false, because we will now normally be using namespaces if available.
MozReview-Commit-ID: L9BbLdoLvLg
--HG--
extra : rebase_source : c737b65551deb134de18028714774e0aabb5baf5
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 was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Since encryption can be somewhat CPU intensive, if we're encrypting
a large number of strings we want to be able to do so in a background
thread. This will be consumed by the profile migrators when importing
logins.
MozReview-Commit-ID: JoJGOgMzZ4u
--HG--
extra : rebase_source : 4677482b4e9b1df7c7ca70a0e817204ef6638cdf
GetPersistentDescriptor is good enough for logging purpose.
MozReview-Commit-ID: DmyW4lT5rT7
--HG--
extra : source : 3d2894427488acc3f9825e6ec4297b35ccbd44f1
extra : intermediate-source : 584662fbeb69351ab4e96afe2ed332916696b130
With this change, the macOS content sandbox has no ability to create files
anywhere on disk (in release builds). If the content process needs a file to
write to, it needs to obtain a file descriptor from the parent process.
MozReview-Commit-ID: 7LoG1PW0UDR
--HG--
extra : rebase_source : 4ac0a7f187d45c9b6c0f8a658edfdae0509054ac
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
The X11 symbol interposition isn't enough, possibly because Cairo can
also use XCB. Interposing XCB is more difficult because the API exposes
more protocol details. Instead, just allow shmget to be called and
fail; this will tell Cairo that it can't use SysV IPC with the X server,
which is what we want.
MozReview-Commit-ID: 5y9tE7UXMTE
--HG--
extra : rebase_source : bb1e81116742a299bc4e412062327e69032ab3b3
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
J.C. Jones
Franziskus Kiefer
Valentin Gosu
Tiberius Oros
ffxbld
Patrick McManus
Sebastian Hengst
Florian Quèze
Csoregi Natalia
Felipe Gomes
David Keeler
Jed Davis
Jonathan Kingston
Chris Peterson
Gurzau Raul
Narcis Beleuzu
Margareta Eliza Balazs
David Parks
Dorel Luca
Haik Aftandilian
Ciure Andrei
Markus Stange
Tom Ritter
Bogdan Tara
Coroiu Cristina
Brendan Dahl
Honza Bambas
Andrew McCreight
Cykesiopka
Emilio Cobos Álvarez
Noemi Erli
Nathan Froyd
Andrew Halberstadt
Gian-Carlo Pascutto
Brindusan Cristian
Bob Owen
Boris Zbarsky
Alex Gaynor
shindli
Andreea Pavel
Kris Maglione
Jorg K
Cosmin Sabou
Masatoshi Kimura
Doug Thayer
arthur.iakab
Thomas Wisniewski
Harald van Dijk
Gian-Carlo Pascutto
Tim Nguyen
Jorg K
Kai Engert