This patch moves all TLS error string handling to the frontend.
Dev-tools doesn't show the same error code as the page does anymore but only the error code as string.
All logging of these error messages has been removed.
Bug #: 1415279
Differential Revision: https://phabricator.services.mozilla.com/D607
--HG--
extra : rebase_source : 61e2d94cb21ef4c02b81448531609205c85a9707
We're seeing a crash in tests from trying to release the promise in
this runnable from the background thread we create to run this
method. The only way I can see that happening is that the bg thread
loses the race with the main thread to drop its reference to the
runnable, causing it to call the destructor. Rather than calling the
helper that adds a reference to the runnable and then forgets it,
let's just forget it here.
MozReview-Commit-ID: LXpC8Kr2SBb
--HG--
extra : rebase_source : bfed3ed4128c6a3ede6f06feed1f50cb9f30e485
Bug 1441223 added MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED to be
emitted when we hit certificates affected by the Symantec distrust.
Since some sites have multiple certificate trust paths possible, sometimes
SEC_ERROR_UNKNOWN_ISSUER is emitted instead of the more specific error.
This patch uses a flag to ensure that the specific error is emitted out of the
Cert Verifier.
--HG--
extra : rebase_source : a961d2e713ae342222d85dff6f83ed3bcaa8006b
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 05dc54b46063967e959bc3fced21c61e5463de48
Adds additional sysctls that are used by the Flash plugin process and alphabetize the list.
MozReview-Commit-ID: 7CaPtaKe874
--HG--
extra : rebase_source : 909228ef9617029eaf7cb16565751150cd1c7404
Remove access to DARWIN_USER_CACHE_DIR. Limit DARWIN_USER_TEMP_DIR
access to the FlashTmp subdirectory. Remove xattr read access to
~/Library/Caches/ and ~/Library/Preferences.
MozReview-Commit-ID: 9svk0BoxVXs
--HG--
extra : rebase_source : 5ea9c7ecc0189455eceb190fb300170d42d0b890
Replace the boolean pref "security.sandbox.mac.flash.enabled"
with "dom.ipc.plugins.sandbox-level.flash" to support sandbox
levels and be consistent with the Windows pref name.
Adds filesystem read access to the sandbox using sandbox extensions
granted by the file dialog machinery (level 1).
Add support for level 2 which blocks read access.
Allow the sandbox to be disabled with MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 4rfobEoxQpF
--HG--
extra : rebase_source : 87f2f00867c4522ae3102abbc44fd05db63c7ec7
Adds additional sysctls that are used by the Flash plugin process and alphabetize the list.
MozReview-Commit-ID: 7CaPtaKe874
--HG--
extra : rebase_source : 078697987ac7fec77c75953035b924422fc93066
Remove access to DARWIN_USER_CACHE_DIR. Limit DARWIN_USER_TEMP_DIR
access to the FlashTmp subdirectory. Remove xattr read access to
~/Library/Caches/ and ~/Library/Preferences.
MozReview-Commit-ID: 9svk0BoxVXs
--HG--
extra : rebase_source : 669c4fa446c9cab6b32cf60091e91eae2d08625f
RenderDoc, a graphics debugging tool, uses a preload library that
creates a listening socket (Internet-domain) early in startup and
accepts connections from the frontend. If it's detected (via env vars),
we allow accept/accept4 (but not socket/bind/listen), and remain in
the parent process's network namespace so that other processes can
connect to the socket.
This doesn't change the sandbox policy if not running under RenderDoc.
MozReview-Commit-ID: 964RW4BFh4u
--HG--
extra : rebase_source : d4a954e68431d84fa2e0edea4171421a948794af
This is to support WebGL with hybrid graphics drivers that connect to
a secondary X server for GL (Primus and VirtualGL), without allowing
access to arbitrary sockets. In addition to local X11 connections,
Primus needs to connect to the Bumblebee daemon (otherwise it will exit
the calling process).
The broker support is limited to AF_UNIX, to non-datagram sockets (see
bug 1066750), and to pathname addresses. Abstract addresses could
theoretically be handled but there isn't currently a compelling reason
to, and the broker very much assumes it's dealing with a C-style string
referring to a filesystem path and not an arbitrary byte sequence
(including NULs).
At a higher level: If the GPU X server is remote then it won't work,
but it won't work anyway because WebGL requires features that aren't
supported by indirect GLX. If the GPU X server is local but the browser
is inside a chroot, it will fail to connect unless /tmp/.X11-unix is
bind-mounted into the chroot; hopefully this use case is not common.
MozReview-Commit-ID: IvI2jYDRZZ2
Factor out the ATI-based driver detection code and use this to set
specific permissions needed by this driver. In passing, unnest some
of the SandboxBroker fallback paths, and make it properly report
the operation in all error paths.
MozReview-Commit-ID: FrRpicj5NF
--HG--
extra : rebase_source : 1410cdddcf1264dc1572f9b9b691f9d08a2061cf
The SandboxLaunchPrepare currently bails out early if it detects a
lack of user namespaces. Hoist the check for drivers needing SysV
IPC up so it's done before that early exit, and the required env
variables get correctly set.
With this we no longer fail with a SIGSYS sandbox error, though
in a debug build we still crash because many assumptions in the
graphics stack get broken when that fails to initialize the driver
for WebGL.
MozReview-Commit-ID: 8n3Hx6VSjTF
--HG--
extra : rebase_source : 99bf2d25a7435b0eb95f186a00cc7723a196be4c
Per the Consensus plan, this patch enforces the distrust of Syamntec roots from
Bug 1409257. It is ultimately destined for Firefox 60.
MozReview-Commit-ID: 8Vpxdflk9Wu
--HG--
extra : rebase_source : 39dddbdc5fd18a692c0588c57c7fd8c4604ea76c
Certificate verification failures that result from additional policy constraint
failures now use the error code
"MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED" (also known as
"Result::ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED", depending on the context).
MozReview-Commit-ID: 9rE7gRBapRF
--HG--
extra : rebase_source : 9a60900a86f9eebab58b973f3e8f776b2481a1ff
This adds the pref "security.pki.distrust_ca_policy" which, if set to 1,
enforces the graduated distrust from Bug 1409257, and if set to 0 (as it is in
this patch) disables that distrust.
This pref is intended to outlast the Symantec distrust, and instead be able to
extend to enable/disable future root policy actions. It would need its own
tests for that, in the future.
MozReview-Commit-ID: BAZfkapysfX
--HG--
extra : rebase_source : 02b00aa486e9f8efb81b32d38d80db5cae86bc6e
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 {, <