Namespace sandbox: add check for unprivileged use of CLONE_NEWUSER

sandbox/linux/suid/client/setuid_sandbox_client.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "sandbox/linux/suid/client/setuid_sandbox_client.h"
 
 #include <fcntl.h>
 #include <sys/stat.h>
 #include <sys/wait.h>
 #include <unistd.h>
 
 #include <string>
 #include <utility>
 
 #include "base/environment.h"
 #include "base/files/scoped_file.h"
 #include "base/logging.h"
 #include "base/posix/eintr_wrapper.h"
 #include "base/strings/string_number_conversions.h"
 #include "sandbox/linux/suid/common/sandbox.h"
 
 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();
 }
 
 int GetHelperApi(base::Environment* env) {
   std::string api_string;
   int api_number = 0;  // Assume API version 0 if no environment was found.
   if (env->GetVar(sandbox::kSandboxEnvironmentApiProvides, &api_string) &&
       !base::StringToInt(api_string, &api_number)) {
     // It's an error if we could not convert the API number.
     api_number = -1;
@@ skipping 106 matching lines @@
 
 bool SetuidSandboxClient::IsInNewNETNamespace() const {
   return env_->HasVar(kSandboxNETNSEnvironmentVarName);
 }
 
 bool SetuidSandboxClient::IsSandboxed() const {
   return sandboxed_;
 }
 
 }  // namespace sandbox