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
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
fork() will now fail with EPERM instead of crashing; see code comment
and bug for more info. Tested with GTK3 Oxygen theme and SCIM, which
both seem to work. Also verified that GMP child processes still crash
on fork().
--HG--
extra : rebase_source : 267c4cb892b691502a9d7760bca4d23fee3fe449
For some reason libfontconfig really Needs To Know.
MozReview-Commit-ID: KSET8D5h9xf
--HG--
extra : rebase_source : 10c5df6a4b8b85be120a9828686d0c63e3fff5d4
For 32-bit Linux 4.3+, always add socketcall dispatcher even if relevant
syscalls are known, because both entry points will exist.
See Linux kernel commit:
commit 9dea5dc921b5f4045a18c63eb92e84dc274d17eb
Author: Andy Lutomirski <luto@kernel.org>
Date: Tue Jul 14 15:24:24 2015 -0700
x86/entry/syscalls: Wire up 32-bit direct socket calls
MozReview-Commit-ID: I3GEvolGfsR
--HG--
extra : rebase_source : c358a6d39d9bf5701150e58f1002f6c6dc91cd6f
The preprocessor token HAVE_ANDROID_OS configures 'android_filesystem_config.h'
to include the correct header files from the environment.
MozReview-Commit-ID: oKwdjzDjij
The preprocessor token HAVE_ANDROID_OS configures 'android_filesystem_config.h'
to include the correct header files from the environment.
MozReview-Commit-ID: oKwdjzDjij