Add namespace sandbox class.

sandbox/linux/services/namespace_sandbox.h

+// Copyright 2015 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.
+
+#ifndef SANDBOX_LINUX_SERVICES_NAMESPACE_SANDBOX_H_
+#define SANDBOX_LINUX_SERVICES_NAMESPACE_SANDBOX_H_
+
+#include <sys/types.h>
+
+#include "base/command_line.h"
+#include "base/files/scoped_file.h"
+#include "base/macros.h"
+#include "base/process/launch.h"
+#include "base/process/process_handle.h"
+#include "sandbox/sandbox_export.h"
+
+namespace sandbox {
+
+// Helper class for starting a process inside a new user, PID, and network
+// namespace. Before using a namespace sandbox, check for namespaces support
+// using Credentials::CanCreateProcessInNewUserNS.
+//
+// A typical use for "A" launching a sandboxed process "B" would be:
+// 1. A sets up a command line for process B.
+// 2. A sets up launch options and fd mappings for B using AddFdMapping and
+//    mutable_launch_options.
+// 3. A launches B with Launch.
+// 4. B should be prepared to assume the role of init(1). In particular, apart
+//    from SIGKILL and SIGSTOP, B cannot receive any signal for which it does
+//    not have an explicit signal handler registered.
+//    If B dies, all the processes in the namespace will die.
+//    B can fork() and the parent can assume the role of init(1), by using
+//    CreateInitProcessReaper().
+// 5. B chroots using Credentials::MoveToNewUserNS() and
+//    Credentials::DropFileSystemAccess().
+//
+// An instance of this class may only be used once. The namespace sandbox cannot
+// be nested.
+//
+// Warning: After a process has entered a new PID namespace, /proc/pid still

[jln (very slow on Chromium), 2015/02/02 18:54:45]

Wasn't it nestable before? I don't remember, but didn't the child modify its own
uid map via /proc/self?

This will be problematic since NaCl is in a nested PID NS.

[rickyz (no longer on Chrome), 2015/02/02 21:35:31]

Changed it to write the uid/gid map in the pre_exec delegate as we discussed, so
nested namespace sandboxes are now supported.

+// refers to process ids outside of the PID namespace. As a result, the
+// namespace sandbox cannot be nested.
+class SANDBOX_EXPORT NamespaceSandbox {
+ public:
+  NamespaceSandbox();
+  ~NamespaceSandbox();
+
+  // Launch a new process inside its own user/PID/network namespaces (depending
+  // on kernel support). Requires at a minimum that user namespaces are
+  // supported (use Credentials::CanCreateProcessInNewUserNS to check this).
+  base::Process Launch(const base::CommandLine& cmdline);
+
+  // Adds an fd mapping in the new process. This should be used instead of
+  // modifying fds_to_remap in the launch options.
+  void AddFdMapping(int from_fd, int to_fd);
+
+  // Returns a pointer to the launch options for the sandboxed process. The
+  // following fields of LaunchOptions should not be modified:
+  // pre_exec_delegate, fds_to_remap, clone_flags. Any pointers added to
+  // launch_options must be valid at the time that Launch is called.
+  base::LaunchOptions* mutable_launch_options() { return &launch_options_; }
+
+  // Returns whether the namespace sandbox created a new user, PID, and network
+  // namespace. In particular, InNewUserNamespace should return true iff the
+  // process was started via this class.
+  static bool InNewUserNamespace();
+  static bool InNewPidNamespace();
+  static bool InNewNetNamespace();
+
+ private:
+  // Writes an mappings for the process's uid/gid to /proc/|pid|/{uid,gid}_map,
+  // then unblocks the process by writing to |fd|.
+  void WriteUidGidMapAndUnblockProcess(pid_t pid, base::ScopedFD fd);
+
+  // Whether Launch has been called.
+  bool launch_called_;
+
+  // FD mappings and launch options for the child process.
+  base::FileHandleMappingVector fds_to_remap_;
+  base::LaunchOptions launch_options_;
+
+  DISALLOW_COPY_AND_ASSIGN(NamespaceSandbox);
+};
+
+}  // namespace sandbox
+
+#endif  // SANDBOX_LINUX_SERVICES_NAMESPACE_SANDBOX_H_