Namespace sandbox: add check for unprivileged use of CLONE_NEWUSER

sandbox/linux/suid/client/setuid_sandbox_client.cc

Index: sandbox/linux/suid/client/setuid_sandbox_client.cc
diff --git a/sandbox/linux/suid/client/setuid_sandbox_client.cc b/sandbox/linux/suid/client/setuid_sandbox_client.cc
index ca73d46444e12e386fbd9bed5c99fbcad382ed71..590efa8d2f68119e59cbce99112200c80d8f291c 100644
--- a/sandbox/linux/suid/client/setuid_sandbox_client.cc
+++ b/sandbox/linux/suid/client/setuid_sandbox_client.cc
@@ -22,7 +22,7 @@
 namespace {
 
 bool IsFileSystemAccessDenied() {
-  base::ScopedFD root_dir(HANDLE_EINTR(open("/", O_RDONLY)));
+  base::ScopedFD root_dir(HANDLE_EINTR(open("/proc/self/exe", O_RDONLY)));

[Tom (Use chromium acct), 2016/12/14 04:13:48]

Without this, when running as root, IsFileSystemAccessDenied returns false.

This was originally /proc/self/exe but was changed to / in
https://chromium.googlesource.com/chromium/src/+/10feab647ef8b96609d087f9936e...

I'm not sure why this makes it work, but I figured I'd see if you knew before I
spent a lot of time debugging it.

[mdempsky, 2016/12/14 05:11:11]

Hm, so my best guess is that because with the setuid sandbox, we end up with
filesystem access, but chroot'd into an empty no-permissions directory. And then
because root bypasses filesystem ACLs, we would be able to open "/"
successfully.

Are you able to confirm what UID the sandboxed processes are running as when you
test it?

However, if that's the case (i.e., renderers are running as root), that seems
really bad to me. I'm not sure we actually want to support that case.

[Tom (Use chromium acct), 2016/12/14 21:10:26]

ok that makes sense.
The renderers have uid and gid 0
Yes that does sound bad :(

But we do have a check here:
https://cs.chromium.org/chromium/src/chrome/browser/ui/views/chrome_browser_m...

I like that check because it shows a dialog box rather than just exiting to the
console so if chrome was launched using a gui, the user will know what's wrong. 
However the check lets you run chrome as root with the --user-data-dir flag. 
Maybe we could just unconditionally refuse to run as root?

Also I'm not hitting that check when using the namespace sandbox, but I guess
that's correct behavior?

   return !root_dir.is_valid();
 }