summaryrefslogtreecommitdiffstats
path: root/sandbox/linux/suid
Commit message (Collapse)AuthorAgeFilesLines
* Add NEWNS and NEWNET to the SUID sandbox.agl@chromium.org2010-05-241-15/+30
| | | | | | | | | | | | | | | | | | | This patch attempts to fork off the sandboxed process with the additional NEWNS and NEWNET flags. If these flags aren't supported at runtime then the code will degrade to the current behaviour. NEWNS starts children in a new mount namespace so that they cannot affect the parent's mounts. (This is a little bit useless every little helps.) NEWNET starts children in a new network space, initially with no network devices and this stops sandboxed processes from talking to the network. Additionally, children exist in their own namespaces for UNIX domain sockets and the abstract namespace. http://codereview.chromium.org/2108020/show git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48040 0039d316-1c4b-4281-b951-d872f2087c98
* Remove a possible race in the SUID sandbox (minor)agl@chromium.org2010-05-201-7/+18
| | | | | | | | | | | | | | | | | The SUID sandbox can be used to set the oom_adj value for non-dumpable processes owned by the same user. When doing so, we previously first checked the directory owner and then opened the oom_adj file. In between the check and the open, the process could have died and another process could have taken that PID value. We would then adjust the OOM value of the wrong process. Given how PIDs are allocated, this is very hard to exploit and, even then, a minor security issue at best, but we can avoid the issue entirely with openat. http://codereview.chromium.org/2118007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47801 0039d316-1c4b-4281-b951-d872f2087c98
* linux: turn on -Wextraevan@chromium.org2010-03-263-14/+16
| | | | | | | | | | | | | | 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-253-16/+14
| | | | | | | | 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-253-14/+16
| | | | | | | | | | | | 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
* 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
* 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
* 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
* 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
* 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
* 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 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
* 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-02-14 12:42:32 +0000