| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
TBR=thakis@chromium.org
Review URL: http://codereview.chromium.org/2825006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50002 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49982 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention behind this is to make it easier to sync the .gyp file
into the non-Chromium copy of the seccomp sandbox so that it can be
used to build a standalone version of the sandbox.
Also, it arguably makes the .gyp files more manageable.
Removes a dependency on "base", which the seccomp sandbox does not use.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/1939002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47792 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from within the sandbox.
Added tests for the new functionality and merged the tests for sigreturn()
that had previously been committed to the standalone version of the sandbox
(on Google Code)
TEST=run "make test"
BUG=37728
Review URL: http://codereview.chromium.org/2074003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47561 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/1480002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47327 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously assumed that no signals would ever be enabled in the sandbox
and thus there was no way to trick the trusted thread into executing potentially
untrusted code.
In an attempt to lift this restriction, this changelist modifies the trusted
thread so that
- it has an invalid stack pointer at all times. Any attempt to handle a
signal would result in the kernel trying to push a signal stack, which
would immediately result in a SEGV and then terminate the application.
- all signals are blocked while outside of trusted code. If a signal is
triggered, it either gets handled on one of the sandboxed threads (for
asynchronous signals), or it results in the application getting terminated
by the kernel (for synchronous signals).
This changelist is difficult not only because eliminating all uses of the
stack pointer requires some very careful assembly coding, but more importantly
because we have to restore signals after we enter seccomp mode.
As sigprocmask() is a restricted system call, the only way to restore the
signal mask is by calling sigreturn() with a suitably tweaked signal
stack frame. While the first couple of bytes of the signal stack frame are
well-defined and unlikely to change, the entire signal stack frame is not
documented as part of the stable ABI. The exact format depends on the number of modified CPU registers (e.g. SSE, MMX, floating point, ...)
The only way for us to get a valid signal stack frame is to trigger a
signal, and to create a (possibly adjusted) copy of the signal frame. We
obviously have to do this _before_ we block all signals upon entering
trusted code.
The two places where this needs to happen is upon start of the sandbox when
launching the initial trusted thread, and upon any call to clone().
BUG=37728
TEST=Run chrome and verify that /proc/$PID/status shows the correct signal mask for trusted threads. The latter can be identified with strace.
Review URL: http://codereview.chromium.org/1594040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45055 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
sandbox.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/1076001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41917 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Enable registry, file and event policy
- Now sbox_integration_tests.exe runs and all tests pass
BUG=27218
TEST=included
Review URL: http://codereview.chromium.org/992003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41673 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- broke integration tests
See http://codereview.chromium.org/757001
BUG=27218
TEST=included
No change in the original files.
The only changes are in the files:
sandbox/src/registry_dispatcher.cc
sandbox/src/registry_dispatcher.h
sandbox/src/filesystem_dispatcher.cc
Because now even in 32 bits the handles map to void pointers
Review URL: http://codereview.chromium.org/873006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41523 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handling pointer sized items
Beefing up unit tests
Beefing up integration tests
Enabling Process, Thread and Token IPCs
Making validation tests compile again
BUG=27218
TEST= unit tests included
Review URL: http://codereview.chromium.org/757001
TBR=cpu@chromium.org
Review URL: http://codereview.chromium.org/871008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41491 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Handling pointer sized items
- Beefing up unit tests
- Beefing up integration tests
- Enabling Process, Thread and Token IPCs
- Making validation tests compile again
BUG=27218
TEST= unit tests included
Review URL: http://codereview.chromium.org/757001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41481 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This sets up useful flags like -Wall -Werror etc.
Also squash a compiler warning:
sandbox/linux/suid/process_util_linux.c: In function ‘AdjustOOMScore’:
sandbox/linux/suid/process_util_linux.c:25: error: format ‘%lu’ expects type ‘long unsigned int’, but argument 4 has type ‘pid_t’
BUG=none
TEST=try-servers
Review URL: http://codereview.chromium.org/733001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41161 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
were observed on some machines (in particular in 32bit mode).
- Some more changes to avoid calling into glibc when we can make a direct
system call, instead. These particular call sites were unlikely to cause
any problems. But it makes the code easier to audit if we avoid all
unnecessary calls into glibc.
- In 64bit mode, gettimeofday() is handled by vsyscalls and tends to be cheap.
In 32bit mode, it is just a regular system call. Some users rely on being
able to call gettimeofday() at a very high rate (up to thousands of
consecutive calls). Recognize this system call pattern and optimize for it.
- Add debugging option that allows us to warn about expensive system calls.
In many cases, these warnings can then be used to optimize the sandboxed
application.
- Fix compilation on newer versions of gcc.
- Changed the x86-32 version of the code that we use when intercepting
system calls. Previously, we would use CALL to jump to the set of
instructions that we had relocated. But we made the mistake of allowing
relocation of instructions that reference %esp. This doesn't work, as
CALL modifies the stack. We now avoid using CALL and instead jump
directly. On x86-32 that requires the use of a PUSH/RET combination as
there is no 32bit wide JMP instruction.
The x86-64 version of the code was already written in a way that would
avoid this particular problem.
(I would like to thank Craig Schlenter for his exceptional detective
work in tracking down the root cause of this bug!)
- For debugging purposes, injected a really small library (less than 4kB)
and discovered that some of our memory map manipulations implicitly
relied on mappings to be at least two pages long. Fixed the code that
made this incorrect assumption.
- For really small libraries, the runtime linker can choose a different
more compact layout. Our computation of the ASR offset did not know how
to deal with that. Fixed by explicitly looking for a ".text" segment
instead of looking for a PT_DYNAMIC section.
- Closed a file descriptor that we kept open longer than needed.
- Removed some unused code.
- Added copyright headers
TEST=tested on i386 and x86-64
BUG=36133
Review URL: http://codereview.chromium.org/661438
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40900 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Still waiting for IPC to be able to test anything.
BUG=27218
TEST=none
Review URL: http://codereview.chromium.org/669128
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40700 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-IPC unit tests enabled
-Integration IPCTest test enabled
-All unit test pass (62 tests)
Other tests require interceptor fu.
BUG=27218
TEST= unit tests included
Review URL: http://codereview.chromium.org/661299
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40485 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
No real code change.
BUG=27218
TEST=current tests.
Review URL: http://codereview.chromium.org/597050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38837 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unit tests and integration tests run (as long as they don't
depend on IPCs), both regular and under SANDBOX_EXPORTS.
The interception agent is there, but no EAT interceptions yet.
BUG=27218
TEST=unit tests/ integration tests.
Review URL: http://codereview.chromium.org/565026
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38143 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
extra bits of infrastructure.
BUG=27218
TEST=none
Review URL: http://codereview.chromium.org/558032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37764 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=27218
TEST=none
Review URL: http://codereview.chromium.org/552223
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37468 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=28804
TEST=unit tests.
Review URL: http://codereview.chromium.org/553080
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37286 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
broker currently launches with --no-sandbox, so the 64-bit version of the sandbox library is there only to allow successful build.
BUG=27218
TEST=none
Review URL: http://codereview.chromium.org/543058
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36469 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
to the OOM killer.
BUG=29752
TEST=During out of memory conditions, Linux kernel picks a plugin/renderer over the browser process.
Review URL: http://codereview.chromium.org/467058
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34222 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/375018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31449 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
given inode number.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/312003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30931 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=successful builds
Review URL: http://codereview.chromium.org/256059
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28089 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why: Simpler build code. If everybody includes it, it should be included automatically.
Why now: The webkit chromium builds need it be specified, since can't default to build/common.gypi.
What was done:
1. build/common.gypi's contents were moved to a new file build/gyp_chromium.gypi
2. tools/gyp/gyp_chromium was moved to build/gyp_chromium and made to automatically include build/gyp_chromium.gypi.
3. lots of gyp files were fixed to not refer to build/common.gypi any more.
4. o3d which also builds independently of chrome, was fixed to have a gyp_o3d that includes gyp_chromium.gypi too.
5. build/common.gypi was left empty, because there are some external projects that still refer to it.
Things that are left to do after this patch is in:
1. The following external files (in other repositories) need to stop include common.gypi
./third_party/hunspell/hunspell.gyp
./third_party/icu/icu.gyp
./v8/tools/gyp/v8.gyp
2. Once nobody refers to common.gypi anymore, delete common.gypi
-or-
Delete gyp_chromium.gypi and move its content back to common.gypi
Tested on mac, win and linux. On win, got a few unit tests errors on chrome bookmarks, which should not be related. I'm running again with clobber to verify.
Review URL: http://codereview.chromium.org/206006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26302 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for a selinux GYP variable which, when set to
one, does the following:
* Removes the seccomp sandbox from the compile
* Removes support for SUID sandboxing from the zygote
* Performs a dynamic transition, in the zygote, to
chromium_renderer_t.
This code requires that the system policy have a sensible set of
access vectors for the chromium_renderer_t type. Such a policy will be
found in sandbox/selinux in the future.
http://codereview.chromium.org/203071
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26257 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moved versions of those files from sandbox/src/ to base/ (overwrite versions in
base/ to avoid 64-bit warning).
Removed 'sandbox' namespace, adapted other files as necessary.
BUG=8348
TEST=none
Original review URL: http://codereview.chromium.org/179039
Patch by rsteiner
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25611 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
especially when define changes.
TEST=none
BUG=20889
Review URL: http://codereview.chromium.org/171118
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25511 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/181030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25019 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(patch from Julien Tinnes)
* Light changes to make it compile as C99 code instead of C++ (no
variable declaration inside 'for' loops initialization)
* argc = 0 would lead to memory corruption.
* Now always in CHROME_DEVEL_SANDBOX mode:
+ In the previous mode, the trusted binary was attacker-owned anyway
because of the environment variables, so I believe it was trivial
to bypass the check.
+ Remove check for being owned by current user.
* Move all the tmp dir creation stuff *before* CLONE_FS happens: avoid
doing stuff in a scary environment. I closed the fd in the untrusted
process.
* changed if (st.st_uid || st.st_gid || st.st_mode & S_IWOTH) to if
(st.st_uid || st.st_gid || st.st_mode & 0777)
* Check rmdir/fchown/fchmod return values
* Check snprintf return value x3 (probably useless)
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24758 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL moves the seccomp sandbox callsite behind an ifdef arch x86 and makes the gyp target conditional on !ARM.
Patch by Joel Stanley <joel@jms.id.au>
BUG=19953
Review URL: http://codereview.chromium.org/173201
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23984 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
http://code.google.com/p/seccompsandbox/
Make the seccomp sandbox dependant on the --enable-seccomp-sandbox flag
Review URL: http://codereview.chromium.org/165310
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23087 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r20733 added code to save LD_LIBRARY_PATH when using the SUID sandbox.
That fixed a P0, show-stopper bug, however, LD_LIBRARY_PATH isn't the
only variable which is stomped when using SUID binaries. This patch
extends support to all variables that we so affected.
BUG=16815
http://codereview.chromium.org/159025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21009 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the hardcoded paths for the sandbox binary location
and the chrome binary location for the sandbox. Instead, you can now
set GYP variables for these things. Indeed, you have to set a GYP
variable in order to use the sandbox now.
GYP variables can be set on the command line, if you run gyp.py
directly, with -D key=value. Or you can export GYP_DEFINES="key=value
key2=value2".
Now, in order to use the sandbox you should set:
linux_sandbox_path=/opt/google/chrome/chrome-sandbox
linux_sandbox_chrome_path=/opt/google/chrome/chrome
(changing the paths as needed, of course). See the comments in
build/common.gypi
For development see
http://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment
Because developers need to setup a special sandbox binary.
http://codereview.chromium.org/149689
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20801 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The latest google-chrome packages contain a sandbox binary, which the
development builds of chromium will pick up on automatically. However,
for safety reasons, the sandbox binary will only exec a fixed chrome
binary location. Since development builds will be somewhere else in
the filesystem, this means that they will fail to start their zygote
processes and generally be very sad.
However, we /do/ want people developing with the sandbox, but we don't
want the general sandbox binary to be able to exec anything. We could
have chromium try and find its sandbox binary relative to the build
directory, but some people build on NFS and, since the sandbox binary
needs to be SUID, this won't work for them.
Instead, we add a new target: chrome_devel_sandbox which developers
can use. This builds a sandbox binary that will exec anything which is
owned by the running user. This alternative sandbox binary can be
selected by exporting CHROME_DEVEL_SANDBOX.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20709 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20111 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make processes dumpable when they crash.
* Find crashing processes by searching for a socket inode, rather
than relying on SCM_CREDENTIALS. The kernel doesn't translate PIDs
between PID namespaces with SCM_CREDENTIALS, so we can't use the
PID there.
* Use a command line flag to the renderer to enable crash dumping.
Previously it tried to access the user's home directory for this
information.
* Search for a sandbox helper binary and, if found, use it.
* Include the source for a sandbox helper binary. It's currently not
built by default.
http://codereview.chromium.org/149230
R=evan,markus
BUG=8081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20110 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explicitly disable it (/INCREMENTAL:NO) for Release, and for the
following targets that require it:
chrome.dll
interactive_ui_tests.exe
perf_tests.exe
unit_tests.exe
Explicitly specificy /SUBSYSTEM:CONSOLE as default for linking,
and match current practice by overriding with /SUBSYSTEM:WINDOWS for:
chrome.exe
chrome.dll
media_player.exe
sandbox_poc.exe
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/115664
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16698 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
TEST: Start chrome, make sure it loads pages, then user process explorer to make sure the WindowStation handle name is not the same as the browser process.
BUG:10996
Review URL: http://codereview.chromium.org/113190
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16483 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
parameterize the 'type' setting of the various library targets, with a
default of 'static_library'.
(Hat tip to Craig Schlenter.)
Review URL: http://codereview.chromium.org/62127
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13345 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/45052
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12464 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Rolling forward deps on gyp to get 'copies' support.
This time handled wow_helper.
Review URL: http://codereview.chromium.org/42355
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12270 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/42044
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11388 0039d316-1c4b-4281-b951-d872f2087c98
|
|
Got app and unit_tests linking with gyp under windows.
Still missing pieces (things don't run).
Review URL: http://codereview.chromium.org/39319
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11302 0039d316-1c4b-4281-b951-d872f2087c98
|