All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
DConf uses small memory-mapped files for the writer to signal readers
to invalidate cached data; the file is created by the first reader and
readers will write to it to force storage allocation.
If we don't allow opening the file, DConf will still work, but it will
reread the database on every pref access, and it prints messages on
stderr claiming it won't work. So we should avoid that.
MozReview-Commit-ID: 9xoBIhtu5cu
--HG--
extra : rebase_source : 582b3bc30f2181b6564eefa34082a561f9cc0c28
The build warning is for "possible misuse of comma operator".
The comma operator is a bit of a footgun becasue its first operand's result
just gets dropped on the floor (in this case, the result of the DCHECK
expression). It appears that Chromium's use of the comma operator here is
intentional, though -- so we might as well accept clang's suggestion and "cast
expression to void to silence warning".
This is also filed upstream as:
https://bugs.chromium.org/p/chromium/issues/detail?id=729123
MozReview-Commit-ID: Al2xsYEo3p0
--HG--
extra : rebase_source : 68d01b50ff1f07b68ddc0eeb7280ac412ac92932
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : cd5a853c46a5cd334504b339bef8df30a3cabe51
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
This also removes a rule that was added for sandboxing the Java plugin,
which we never did and we now only allow Flash anyway.
MozReview-Commit-ID: Jn6pCkLoGNM
--HG--
extra : source : 431267ab28deabef6ed7c791d8dff79e3fe590c1
This permission was needed for the memory bloat logging, which is used for
leaktest, including logging intentionally crashing processes. Now we restrict
ourselves to only allowing writes to the location needed for this logging,
rather than all of /private/var.
MozReview-Commit-ID: 5AbJEZlDHNV
--HG--
extra : rebase_source : 26936b8d8bca53f2c37a195b5e7c69c151ec18d2
Removes read access to /private/var and its subdirectories from
the content process under the level 3 Mac sandbox. Still permits
reading of file metadata within the majority of /private/var.
Adds tests to validate the level 3 Mac content sandbox prevents
reading from /private.
MozReview-Commit-ID: FO5dz0F7dl4
--HG--
extra : rebase_source : 226f8de6d4d88f188c272a3e119ed7b8bac292df
Remove reading of "~/Library/Caches/TemporaryItems" from level 3 and update
sandboxing filesystem test to check ~/Library/Caches/TemporaryItems readability.
MozReview-Commit-ID: 6EMzH7brSnp
--HG--
extra : rebase_source : f97b5625da2abda73decc969fc581c2bf858183f
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
These directories contain sensitive content, and access is not necessary now that we have file content processes.
r=haik
MozReview-Commit-ID: FiRJkMnlYUx
--HG--
extra : rebase_source : 0bcdefcb1ea410fb26c3f8373673488e2a5fdd75
This API produces much more readable code (though slightly more verbose). While this is not a publicly documented API on macOS, it is used by both WebKit and Chrome.
MozReview-Commit-ID: LVxYT4wBLck
--HG--
extra : rebase_source : 9688981ea0bb4e71f084afc404af705fa68f84a3
This also changes the read only related status checks in filesystem_interception.cc to include STATUS_NETWORK_OPEN_RESTRICTION (0xC0000201), which gets returned in some cases and fails because we never ask the broker.
Carrying r=jimm from original changeset:
https://hg.mozilla.org/mozilla-central/rev/1755a454e2de
MozReview-Commit-ID: 4tfygPiKG9Z
This also changes the read only related status checks in filesystem_interception.cc to include STATUS_NETWORK_OPEN_RESTRICTION (0xC0000201), which gets returned in some cases and fails because we never ask the broker.
Hook this into the browser via the XREAppData. This patch contains only the changes to Chromium source code.
--HG--
extra : rebase_source : f1ddd3bdfb52cef0a2dc8bfbae4ba5c78e7fd7eb
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : 4d5637bcdbeae605b0b99e9192598d48f371b698
Hook this into the browser via the XREAppData. This patch contains only the changes to Chromium source code.
--HG--
extra : rebase_source : 309715aa2449d53456934495b1f5e854df599bfb
extra : histedit_source : 26761a6a33e4e5b2bb559caf3b3eb51c249f2bcd
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : e34e8b50101cc40ded26e80791052123b24c8243
extra : histedit_source : 69c9b2dc91546adbfdad03b5d43842809191ffb9
Adds additional tests that try to read files and get directory listings from
both a web content process and a file content process.
Tests include attempting to read the profile directory and cookies file from
a web content process and validating that this is prevented by the sandbox
when the sandbox level (security.sandbox.content.level) is set high enough.
Only Mac (for now) uses a level that includes read access blocking of the
profile directory.
Tests also attempt to read the profile and cookies file from a file content
process which should be allowed.
MozReview-Commit-ID: KfyT9ohsuuG
--HG--
extra : rebase_source : f1c5aa2fef58a6bb859623072770ea918f8f4df1
If the path given doesn't have write+create permissions in the broker
policy, but does have MAY_ACCESS (i.e., if checking for its existence
with lstat() or access() would be allowed), then check for its existence
and fail with EEXIST the way the the real mkdir() would.
Note that mkdir() fails with EEXIST even the existing file isn't a
directory, including if it's a broken symlink.
MozReview-Commit-ID: 13Cwnq1nRrw
--HG--
extra : rebase_source : c37caa091583fa85a0a72ed62fa9f12a3523e8f4
Update MacSandboxInfo struct to include file system read flag and remove
filesytem read restrictions from the file content process sandbox.
MozReview-Commit-ID: B9LPocvb0W3
--HG--
extra : rebase_source : 7c80335c28dbdb7146d2ad0b447959db5e06cf0f
Assigns the preference security.sandbox.logging.enabled and the environment variable MOZ_SANDBOX_LOGGING to control whether or not sandbox violations are logged. The pref defaults to true. On Linux, only the environment variable is considered.
--HG--
extra : rebase_source : f67870a74795228548b290aec32d08552c068874
Turns on sandbox denial logging if security.sandbox.logging.enabled is true.
Removes most sandbox violation messages but some related messages generated
by other processes will still get through.
--HG--
extra : rebase_source : 4f06e70d53b0f500cc85a869c5bd7f8ea20d8341
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : dfaf13fb4c2185985f4f074c338ccf1fef8f3c94
Adds security/sandbox/test/browser_content_sandbox_fs.js for validating content
sandbox file I/O restrictions.
Adds security/sandbox/test/browser_content_sandbox_syscalls.js for validating
OS-level calls are sandboxed as intended. Uses js-ctypes to invoke native
library routines. Windows tests yet to be added here.
Adds security/sandbox/test/browser_content_sandbox_utils.js with some
shared utility functions.
MozReview-Commit-ID: 5zfCLctfuN5
--HG--
extra : rebase_source : 4edd14220bcd18b15a3c522e44d7223547a79f43
CLOSED TREE
Backed out changeset 01cfc71ce542 (bug 1322735)
Backed out changeset 84c729c41230 (bug 1322735)
Backed out changeset b419aaefae95 (bug 1322735)
With frame pointer omission disabled we should always have usable stacks on Windows. This allows us to remove the MOZ_STACKWALKING define as it will always be enabled.
MozReview-Commit-ID: 54xs3Hf1r4P
--HG--
extra : rebase_source : 5fe27cdeeb464d81fbedc8c02ac187658bd759e7
This applies only to content processes, where we already allow getrlimit
(but not setrlimit). The rule added here does not allow using prlimit64
to set any resource limits or interact with any other process.
MozReview-Commit-ID: nMry3t6QPj
--HG--
extra : rebase_source : ecf792077a672ab1f2c5edf9fbeb915a0d8dd30e
Preloading libmozsandbox allows the symbol interpositions used by
sandboxing to be defined there instead of statically linked into the
executable; this patch also does that.
MozReview-Commit-ID: FL1QWLSKA0S
--HG--
rename : security/sandbox/linux/interpose/SandboxHooks.cpp => security/sandbox/linux/SandboxHooks.cpp
Now that SandboxInfo is always part of libmozsandbox, instead of being
in different places depending on widget, it doesn't need to be a
separate directory anymore.
Also updates a few comments that referenced it.
--HG--
rename : security/sandbox/linux/common/LinuxSched.h => security/sandbox/linux/LinuxSched.h
rename : security/sandbox/linux/common/SandboxInfo.cpp => security/sandbox/linux/SandboxInfo.cpp
rename : security/sandbox/linux/common/SandboxInfo.h => security/sandbox/linux/SandboxInfo.h
This way they'll continue to be at the beginning of the symbol search
path after mozsandbox returns to being a shared library instead of
statically linked into plugin-container.
--HG--
rename : security/sandbox/linux/SandboxHooks.cpp => security/sandbox/linux/interpose/SandboxHooks.cpp
Removes global write access from the content process (instead of
just blocking write access to $HOME) for level 1 and 2 Mac content
sandboxes. Allows writes to /private/var/folders/[0-9][0-9]/ in
DEBUG mode so that leaktest can continue to work.
MozReview-Commit-ID: 635o7Nj9oW1
--HG--
extra : rebase_source : 7e23612f56a31de83307057c1e6d0eaadb937614
Changes the semantics of the security.sandbox.content.level pref on OS X with
respect to file access to the user's home directory. With the fix, Nightly
defaults to 2 while other releases will default to 1. The level values now
have the following meaning.
*) security.sandbox.content.level=0 disables content process sandboxing.
No change here.
*) security.sandbox.content.level=1 blocks write access to the majority of the
home directory.
*) security.sandbox.content.level=2 includes the write access blocking in
level 1, but also blocks both read and write access to ~/Library and $PROFILE
excluding the extensions and weave subdirectories.
Prior to this fix, Nightly defaulted to a value of 1 while all other releases
used 0. The value of 1 meant that read/write access to ~/Library and the
$PROFILE dir (excluding $PROFILE/{extensions,weave}) was prevented.
The strength of a level=1 sandbox is reduced by this with fix,
but level=1 becomes the first ride-the-trains content sandbox candidate,
Nightly changes to level=2, and higher levels still indicate a more
restrictive sandbox.
MozReview-Commit-ID: 7NJAe24T4pU
--HG--
extra : rebase_source : 8cb5ea82004ad631fe688bafffa9dc9979568679
This also reverts the Bug 1287426 Part 8 patch that turned the USER_NON_ADMIN loken into a restricted token.
MozReview-Commit-ID: 9fNeyhAHw55
--HG--
extra : rebase_source : adbe59260d512b5d17b6e3ea6c1fe484c06eb555
Passes the profile dir to the content process as a -profile CLI
option so that the correct profile dir can be used in the OS X content
sandbox rules. Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected
from the content process (apart from a few profile subdirectories) even
when they don't reside in ~/Library.
xpcshell tests invoke the content process without providing a
profile directory. In that case, we don't need to add filesystem
profile dir. read/write exclusion rules to the sandbox.
This patch adds two new macros to the content sandbox rule set:
|profileDir| holds the path to the profile or the emptry string;
|hasProfileDir| is a boolean (1 or 0) that indicates whether or
not the profile directory rules should be added. If |hasProfileDir|
is 0, profile directory exclusion rules don't need to be added
and |profileDir| is not used.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : 3d5b612c8eb3a1d0da028eba277cd9d6f0c9ac00
This is to work around an issue where the call to CoInitializeSecurity in MainThreadRuntime::InitializeSecurity causes the impersonation token, used to give the pre-lockdown permissions, to be replaced with one with no rights.
This only seems to happen when the lockdown token is USER_NON_ADMIN, which is not a restricted token.
MozReview-Commit-ID: 6HFuDFmWLTf
Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : d91d8939cabb0eed36b640766756548a790a301c
Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
--HG--
extra : rebase_source : 7bf426f14f31b35c8b541e6d21183226db9836c7
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
Allow /System/Library/PrivateFrameworks/ to be read from the from the plugin sandbox.
--HG--
extra : rebase_source : 8b71b7daed4792d8ce67131819c90acb2f5891ea
Making readlink() always fail with EINVAL (the result of applying it
to a non-symlink) worked on B2G, but this is not the case on desktop.
(Note: originally the idea for the B2G file broker was that it would
ignore symlinks and map lstat to stat, so that behavior for readlink
would have been consistent, but as eventually implemented it does do
lstat as actual lstat.)
In particular, this seems to be causing something in the graphics
library stack to change what GL renderer it uses (?), and on some
systems the presence of the readlink->EINVAL rule causes it to load a
version of the llvmpipe software renderer with a crash bug, instead of
(we assume) some other driver that works.
jprof is an in-tree profiling tool that runs on Linux.
This fixes the error:
Sandbox: seccomp sandbox violation: pid 29698, syscall 38, args 0 140731305513136 0 830 22509600 1. Killing process.
Sandbox: crash reporter is disabled (or failed); trying stack trace:
Sandbox: frame #01: __GI_setitimer (/build/glibc-GKVZIf/glibc-2.23/time/../sysdeps/unix/syscall-template.S:84)
Sandbox: frame #02: startSignalCounter(unsigned long) (.../mozilla-central/mozilla/tools/jprof/stub/libmalloc.cpp:464)
which occurs during shutdown when running with jprof enabled via the
JPROF_FLAGS environment variable containing JP_DEFER without actually
sending the signal to start jprof. It presumably occurs sooner if jprof
is actually used either via JP_START or by senging a SIGPROF/SIGALRM.
With the patch, these steps run to completion.
MozReview-Commit-ID: Fx4tzEyqIj2
--HG--
extra : transplant_source : %2AU%15F%8A%C5%E6%1D%03%20%1B%F6W%E9%EB%DA%8F%E7f%5D
Adds content sandbox metadata to parent and child crash reports:
Includes the value of pref security.sandbox.content.level,
whether or not the system is capable of sandboxing, if the
sandbox was successfully turned on, and (on Linux systems)
the sandbox capabilities flags.
New crash report keys:
"ContentSandboxLevel" in parent and content
"ContentSandboxCapable" in parent
"ContentSandboxEnabled" in content
"ContentSandboxCapabilities" in content on Linux
Callers should use a UniquePtr to hold the platform handle.
MozReview-Commit-ID: 6BWnyAf4b3a
--HG--
extra : transplant_source : %26%CA%0D%28%08%9BT%97Z%A1%3Dq%CD%21%A1_%EFE%83%0E
extra : histedit_source : 77f8ed3d0fdec6cce0c95469130ade0fb547bb91
