Linux: SUID sandbox support

Linux: SUID sandbox support

  * 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 current not
    built by default.

[Evan Martin, 2009-07-07 21:04:56]

I think you'll need someone like Markus to review the actual meat of this (for
functions like DropRoot, etc. I think it would be good to get someone to verify
you didn't typo euid for ruid or overlook something).

http://codereview.chromium.org/149230/diff/24/1015
File chrome/app/breakpad_linux.cc (right):

http://codereview.chromium.org/149230/diff/24/1015#newcode539
Line 539: if (!parsed_command_line.HasSwitch(switches::kRendererCrashDump))
Is this split out because the renderer/zygote don't have access to the prefs
file that the above branch likely accesses?  If so (or if not, really) could you
add a comment indicating that?

http://codereview.chromium.org/149230/diff/24/1017
File chrome/browser/renderer_host/render_crash_handler_host_linux.cc (right):

http://codereview.chromium.org/149230/diff/24/1017#newcode28
Line 28: static const char kSocketLinkPrefix[] = "socket:[";
Comment like "expected prefix of the target of the /proc/self/fd/3 link for a
socket"

http://codereview.chromium.org/149230/diff/24/1017#newcode91
Line 91: i = pids.begin(); i != pids.end(); ++i) {
this feels like it could fit on one line

http://codereview.chromium.org/149230/diff/24/1017#newcode120
Line 120: continue;
From 106 to here looks like a copy of code in FileDescriptorGetInode.  It seems
you could share code for "read this link and give me the inode from it".

http://codereview.chromium.org/149230/diff/24/1018
File chrome/browser/zygote_host_linux.cc (right):

http://codereview.chromium.org/149230/diff/24/1018#newcode47
Line 47: chrome::kBrowserProcessExecutableName +
You could just WideToASCII this rather than sticking L's on your static strings.
 *shrug*

http://codereview.chromium.org/149230/diff/24/1019
File chrome/browser/zygote_main_linux.cc (right):

http://codereview.chromium.org/149230/diff/24/1019#newcode237
Line 237: "process and sequestrate it.";
I find the use of the word "sequestrate" here pretty funny.  (I imagine our
Chinese-speaking users trying to look it up in their dictionaries...)

Any thoughts on adding to this some note on how to remedy it?  (The binary
should a-r+x?) Should this be LOG(FATAL)?

http://codereview.chromium.org/149230/diff/24/1022
File sandbox/linux/suid/sandbox.cc (right):

http://codereview.chromium.org/149230/diff/24/1022#newcode25
Line 25: static const char kSandboxPath[] = "/var/run/chrome-sandbox";
You could put the majority of the file in an anonymous namespace and avoid all
these "static"s.

http://codereview.chromium.org/149230/diff/24/1022#newcode26
Line 26: static const char kChromeBinary[] = "/opt/google/chrome/chrome";
fta will be sad about this

http://codereview.chromium.org/149230/diff/24/1022#newcode28
Line 28: static const char kMsgChrootMe = 'C';
comments on these?

http://codereview.chromium.org/149230/diff/24/1022#newcode41
Line 41: static int CloneChrootHelperProcess() {
Comments on these would be nice.  The function names are descriptive, but I'd
like to see info like "what is the chroot helper process?"

http://codereview.chromium.org/149230/diff/24/1022#newcode208
Line 208: FatalError("execv failed");
Don't you need to return a value from main to make the compiler happy?