summaryrefslogtreecommitdiffstats
path: root/sandbox/linux
Commit message (Collapse)AuthorAgeFilesLines
* Merged Mark Seaborn's changes:markus@chromium.org2010-04-2218-76/+427
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some automated tests for seccomp-sandbox This covers some of the syscalls that are proxied by the trusted process. This adds a basic test runner framework. Fix error return code for open() and other syscalls on x86-64 On error, the open() syscall was returning errno & 0xffffffff in %rax on x86-64 instead of -errno. This stops glibc from regarding this as an error, and so its syscall wrapper returns -errno instead of -1 and does not set errno. I have fixed up the other syscalls to use long (64-bit) instead of int (32-bit) as well. Not all of them were affected by the problem: it depends on gcc's code generation. Sometimes casting to int truncates a value, sometimes it doesn't. It seems better to be consistent though. Adds a test for open() and some other syscalls. TODO: Need to figure out how to run the tests automatically BUG=none TEST=none Review URL: http://codereview.chromium.org/1729003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45379 0039d316-1c4b-4281-b951-d872f2087c98
* Make the use of signals inside of the sandbox safe.markus@chromium.org2010-04-2011-409/+964
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SELinux: add basic policy.agl@chromium.org2010-04-193-0/+53
| | | | | | | | | | | | | | | | This patch removes the chromium_zygote_t type and adds a chromium_renderer_t type. Also, a basic policy for chromium_renderer_t is included. I decided not to try to have a different policy for the zygote since it just makes things more complex for little reason. BUG=none TEST=none http://codereview.chromium.org/1104002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44908 0039d316-1c4b-4281-b951-d872f2087c98
* Fix SELinux warnings when running on Fedora.markus@chromium.org2010-03-301-3/+3
| | | | | | | | | | | | (c.f. http://people.redhat.com/drepper/selinux-mem.html) Fix compilation warnings on Fedora. BUG=none TEST=when running Chrome on Fedora, verify that we don't get AVC warnings Review URL: http://codereview.chromium.org/1535004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43107 0039d316-1c4b-4281-b951-d872f2087c98
* Update/add copyright headers.markus@chromium.org2010-03-293-30/+13
| | | | | | | | BUG=32501 TEST=none Review URL: http://codereview.chromium.org/1574001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42992 0039d316-1c4b-4281-b951-d872f2087c98
* linux: turn on -Wextraevan@chromium.org2010-03-267-22/+22
| | | | | | | | | | | | | | This is a followup to an earlier change (r38266) which did most of the warning-related cleanup. This one just flips the flag, and fixes some new warnings that crept in during the window while the flag was off. Second try, now with some libpng fixes. BUG=34160 Review URL: http://codereview.chromium.org/1320011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42700 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "linux: turn on -Wextra"evan@chromium.org2010-03-257-22/+22
| | | | | | | | Compiled locally and on trybots but failed on builder?! This reverts commit r42688. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42689 0039d316-1c4b-4281-b951-d872f2087c98
* linux: turn on -Wextraevan@chromium.org2010-03-257-22/+22
| | | | | | | | | | | | This is a followup to an earlier change (r38266) which did most of the warning-related cleanup. This one just flips the flag, and fixes some new warnings that crept in during the window while the flag was off. BUG=34160 Review URL: http://codereview.chromium.org/597023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42688 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a few more places where we need to use our own allocator.markus@chromium.org2010-03-252-5/+19
| | | | | | | | | | Make tcmalloc compatible with the seccomp sandbox by avoiding making direct system calls from within tcmalloc. BUG=38973 TEST=none Review URL: http://codereview.chromium.org/1294001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42667 0039d316-1c4b-4281-b951-d872f2087c98
* Add #include to fix compile errors on "Linux Perf (webkit.org)" bot.yutak@chromium.org2010-03-181-0/+1
| | | | | | | | | | TBR=markus BUG=none TEST=none Review URL: http://codereview.chromium.org/1107001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41931 0039d316-1c4b-4281-b951-d872f2087c98
* Add a first version of a tool for analyzing performance data output by themarkus@chromium.org2010-03-181-0/+190
| | | | | | | | | | 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
* Compute and pring the time that it takes to execute system calls. This datamarkus@chromium.org2010-03-1820-84/+327
| | | | | | | | | | | | is going to be skewed slightly, as calling gettimeofday() by itself also takes a little bit of time. But it should be good enough to allow us to see where we have performance bottlenecks. TEST=none BUG=none Review URL: http://codereview.chromium.org/997009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41905 0039d316-1c4b-4281-b951-d872f2087c98
* Make sandbox code compile as "chromium_code".craig.schlenter@chromium.org2010-03-101-2/+3
| | | | | | | | | | | | | | | | 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
* Added missing copyright header.markus@chromium.org2010-03-0822-0/+88
| | | | | | | | BUG=32501 TEST=none Review URL: http://codereview.chromium.org/672011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40946 0039d316-1c4b-4281-b951-d872f2087c98
* - Add a custom allocator for STL objects. This fixes sandbox failures thatmarkus@chromium.org2010-03-0812-218/+641
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Be more restrictive when finding file names for libraries that need patching.markus@chromium.org2010-02-241-2/+17
| | | | | | | | | | | | | | | | | | | | | This avoids false positives if the directory name matches one of the well-known library names (e.g. ld). False positives not only result in a performance hit at startup, because we are now trying to instrument libraries that don't actually contain any system calls; but even worse than this, we could try to instrument system calls in the sandboxing code itself. And those system calls are deliberately coded so that they will not get rewritten. Fortunately, none of this is a security problem. If we accidentally rewrite system calls that weren't supposed to be rewritten, we will just crash on startup. TEST=the sandbox now works on the buildbots BUG=36133 Review URL: http://codereview.chromium.org/652188 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39839 0039d316-1c4b-4281-b951-d872f2087c98
* Explicitly ask for unsigned values when comparing addresses. Not only is thismarkus@chromium.org2010-02-241-2/+2
| | | | | | | | | | | code hard to understand (and possibly broken) otherwise, some versions of GCC complain about the comparison without the cast. TEST=none BUG=none Review URL: http://codereview.chromium.org/657034 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39838 0039d316-1c4b-4281-b951-d872f2087c98
* Treat calls to lstat() and lstat64() the same as calls to stat(). In practise,markus@chromium.org2010-02-243-17/+72
| | | | | | | | | | | | | | | this means the calls will still be denied. But we now return a correct return code. But more importantly, this change brings the source code in line with the code of the stand-alone opensource sandbox. Wherever possible, we try to keep both code bases identical. TEST=none BUG=none Review URL: http://codereview.chromium.org/657040 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39837 0039d316-1c4b-4281-b951-d872f2087c98
* If /tmp is not a POSIX file system, try to use /dev/shm for creating ourmarkus@chromium.org2010-02-231-3/+58
| | | | | | | | | | | temporary directory. BUG=30926 TEST=tested with tmpfs, ext3 and NFS Review URL: http://codereview.chromium.org/650177 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39679 0039d316-1c4b-4281-b951-d872f2087c98
* linux: change a type in the sandbox to fix a warningevan@chromium.org2010-02-151-1/+1
| | | | | | | | | int and long are the same size on the platforms we care about, but gcc doesn't like comparing int against LONG_MAX. Review URL: http://codereview.chromium.org/604056 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39071 0039d316-1c4b-4281-b951-d872f2087c98
* seccomp: allow dup/dup2evan@chromium.org2010-02-031-0/+2
| | | | | | | | | | This is needed for opening the renderer<->plugin channel. TEST=flash works in seccomp mode Review URL: http://codereview.chromium.org/563024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38037 0039d316-1c4b-4281-b951-d872f2087c98
* linux: make the seccomp sandbox work againevan@chromium.org2010-01-081-12/+54
| | | | | | | | | | | | | | | | | We were hitting a stack overflow on renderer startup, because of the following: When we patch out syscalls, we need a scratch space near (within a 32-bit jump) of the original code. We pick the scratch space as the end of the nearest empty region available before the code we're patching. For the vdso region, the stack lies directly before it and so the region we'd grab was directly before the stack. This meant that as soon as the stack attempted to grow it'd fail because it ran into our patch region, and we'd hit a stack overflow. The fix is to specially note when we're near the stack region, and instead put our scratch space as far away from the stack as possible. Review URL: http://codereview.chromium.org/518071 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35759 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Adjust /proc/pid/oom_adj to sacrifice plugin and renderer processes ↵thestig@chromium.org2009-12-103-1/+81
| | | | | | | | | | 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
* Allow the seccomp sandbox to be enabled, even if the suid sandbox hasmarkus@chromium.org2009-11-0720-103/+141
| | | | | | | | | | already put a chroot() jail around it. The only tricky part is access to /proc/self/maps, but we can safely pass in an open file descriptor. BUG=26527 Review URL: http://codereview.chromium.org/371047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31372 0039d316-1c4b-4281-b951-d872f2087c98
* linux: compile fix for chrome_sandbox on 64-bit karmicevan@chromium.org2009-11-041-0/+1
| | | | | | | | You need <limits.h> for ULLONG_MAX. Review URL: http://codereview.chromium.org/355025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30978 0039d316-1c4b-4281-b951-d872f2087c98
* Only enable the seccomp sandbox, if the machine actually has kernel support formarkus@chromium.org2009-11-043-1/+66
| | | | | | | | | | | | | this feature, and if no other obstacle prevents us from enabling it. Otherwise, we print a warning message and continue running without the sandbox. This is not ideal, but given the non-trivial number of users who might not have seccomp enabled by default, this seems the prudent approach. BUG=26521 Review URL: http://codereview.chromium.org/341092 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30966 0039d316-1c4b-4281-b951-d872f2087c98
* Allow chrome_sandbox to act as a helper program and find the socket with a ↵thestig@chromium.org2009-11-043-4/+162
| | | | | | | | | | 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
* GCC's optimizer is getting more aggressive. It is no longer goodmarkus@chromium.org2009-10-223-7/+14
| | | | | | | | | | | | | | | | | | | | enough to just pass the address of a structure as an input parameter to assembly code. The assembly code must also mark "memory" as getting clobbered, even if it only wants to read from the structure. This seems to be a result of strict aliasing and the lack of an ability for the assembly code to clearly say which pointers it dereferences. Furthermore, if the assembly code touches the stack (e.g. uses "push"), it must now mark the stack pointer as getting clobbered. Otherwise, GCC assumes that the red zone won't be clobbered, and that it is possible to use the stack pointer as an input register. BUG=none TEST=none Review URL: http://codereview.chromium.org/320008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29829 0039d316-1c4b-4281-b951-d872f2087c98
* - found all symbols that we directly access from assembly and marked them as ↵markus@chromium.org2009-10-2113-486/+210
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | internal. This ensures that the linker won't complain about IP relative addressing for symbols that could be overridden at run-time. - avoided using "g" register constraints, as there has been a report of some versions of GCC erroneously generating code that is no longer position independant when this constraint is used. - removed the old code that fork()'s a child to try to extend mappings of libraries at run-time. This code always was somewhat fragile and caused a measurable performance penalty when the sandbox was started. Replaced with code that remapped just the very first page. This can actually be done in a running process without disrupting the use of the libraries. - added a special case for the instrumentation code allowing it to deal with jumps between the VDSO and VSyscalls even if the instructions would normally not be eligible for interception as they are IP relative. After making this change, we can again find sufficiently large code snippets to rewrite them successfully. This is only a concern on x86_64. - fixed a bug that would erroneously look for IP relative addressing on x86_32. It doesn't exist for that architecture. TEST=none BUG=http://code.google.com/p/chromium/issues/detail?id=18337 Review URL: http://codereview.chromium.org/306036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29726 0039d316-1c4b-4281-b951-d872f2087c98
* Fix minor compilation issues that can trigger on some platforms (e.g. CentOS)markus@chromium.org2009-09-142-2/+2
| | | | | | | | TEST=none BUG=none Review URL: http://codereview.chromium.org/204012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26175 0039d316-1c4b-4281-b951-d872f2087c98
* Despite the futex(2) manual page telling us to include <linux/futex.h>, thismarkus@chromium.org2009-09-142-1/+59
| | | | | | | | | | | | | is neither sufficient nor necessary. The header does not actually include a definition for futex(). And while it does include definitions for useful constants, the version of the file that is shipped by some distributions (e.g Centos) doesn't even compile as it is meant to only be used by the Linux kernel. TEST=none BUG=none Review URL: http://codereview.chromium.org/193104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26167 0039d316-1c4b-4281-b951-d872f2087c98
* On Linux, move the passing of filedescriptors to a dedicated socketpair().agl@chromium.org2009-09-041-1/+1
| | | | | | | | | | | | | | | | | (Patch by Markus) This allows the fast path to use read()/write() instead of recvmsg()/sendmsg() which is much cheaper for the Seccomp sandbox. Also, fixed minor seccomp sandbox issues discovered by this change. BUG=19120 ISSUE=164373 http://codereview.chromium.org/177049 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25518 0039d316-1c4b-4281-b951-d872f2087c98
* Clean out leftover bits of the path-based Linux SUID sandbox.thestig@chromium.org2009-09-011-4/+0
| | | | | | | | 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
* Linux: updates to the SUID sandboxagl@chromium.org2009-08-281-84/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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
* Linux: fix seccomp sandbox for GCC 4.4agl@chromium.org2009-08-131-2/+4
| | | | | | | http://codereview.chromium.org/164484 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23318 0039d316-1c4b-4281-b951-d872f2087c98
* Linux sandbox: fix security issue.agl@chromium.org2009-08-121-2/+6
| | | | | | | | | | | | | | | | | | | | | (Reported by Julien Tinnes) Because the chroot helper process and the zygote share a FILES structure, the latter can race the former and change the value of cwd before it does chroot("."). Because of this, the zygote could chroot into a directory of its choosing. Once there, it could setup hardlinks to SUID binaries and possibly make them misbehave if they weren't sufficiently paranoid. This possibility should have been migigated by the removal of dangerous environment variables. However, we had to reinstate them in order to pass LD_LIBRARY_PATH because some setups don't have ld.so setup to use /usr/lib32 and also for ffmpeg. http://codereview.chromium.org/164427 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23228 0039d316-1c4b-4281-b951-d872f2087c98
* Fix seccomp sandbox for gcc44markus@chromium.org2009-08-122-2/+2
| | | | | | | | | | | | Constness of return values and paramaters were causing compiler errors. BUG=19120 ISSUE=164373 Review URL: http://codereview.chromium.org/164414 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23202 0039d316-1c4b-4281-b951-d872f2087c98
* Initial version of the Seccomp sandbox. Imported from ↵markus@chromium.org2009-08-1136-0/+11365
| | | | | | | | | | | 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
* Linux sandbox: save full list of SUID unsafe environment variables.agl@chromium.org2009-07-172-7/+78
| | | | | | | | | | | | | 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
* Linux sandbox: comment typo fix.agl@chromium.org2009-07-171-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20961 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: move hardcoded paths to GYP variables.agl@chromium.org2009-07-151-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Linux: add comment to the sandbox binary as suggested by Markus.agl@chromium.org2009-07-151-1/+3
| | | | | | | (Because, otherwise, that chunk of code looks pretty scary.) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20746 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: propagate LD_LIBRARY_PATH through the SUID sandbox.agl@chromium.org2009-07-151-0/+15
| | | | | | | | | | | | With the SUID sandbox, certain environment variables (esp LD_LIBRARY_PATH) are cleared for security reasons. This means that the child zygote process isn't run with the correct environment and can fail to start. BUG=16815 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20733 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Fix sandbox defineagl@chromium.org2009-07-151-1/+1
| | | | | | | | | | build/common.gypi used CHROME_DEVEL_SANDBOX, while sandbox.cc was looking for DEVELOPMENT_SANDBOX (Patch by Joel Stanley) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20718 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: various sandbox changesagl@chromium.org2009-07-151-0/+6
| | | | | | | | | | | | | * In development mode, don't let the sandbox run SUID or SGID binaries * Only obay CHROME_DEVEL_SANDBOX if the binary UID matches the read UID. * Change the default sandbox path to save those who do nothing. R=markus git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20710 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: fix for developing on a machine with google-chrome packages installed.agl@chromium.org2009-07-151-0/+40
| | | | | | | | | | | | | | | | | | | | | | | 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
* Linux: don't bother passing the chroot directory fd to the zygote.agl@chromium.org2009-07-101-19/+3
| | | | | | | | | | | | | Markus pointed out that the cwd was already shared between the chroot helper process and the zygote, therefore we could avoid some complexity in passing the file descriptor so, also, we could then make the directory mode 0000. http://codereview.chromium.org/155366 BUG=16363 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20398 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: use a temp directory for the chroot.agl@chromium.org2009-07-101-6/+41
| | | | | | | | | | | | | | | Ubuntu systems (at least) wipe /var/run at boot time, which is deleting our sandbox directory. Instead, we have the SUID helper create a temp directory in /tmp, unlink it and use that for the chroot directory. A file descriptor is passed to the zygote process for it to fchdir into. (Thanks to fta for discussions on this.) BUG=16363 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20388 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: SUID sandbox supportagl@chromium.org2009-07-081-0/+224
* 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
generated by cgit v1.1 at 2025-01-20 20:44:32 +0000