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 "base/files/scoped_file.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 calls SetupLaunchOptions which sets up the a pipe for communicating with
+//    the child.
+// 3. A launches B with base::LaunchProcess.
+// 4. A calls PrepareSandboxedProcess, at which point B begins running.
+// 5. 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().
+// 6. B chroots using Credentials::MoveToNewUserNS() and
+//    Credentials::DropFileSystemAccess().
+//
+// An instance of this class may only be used once.
+class SANDBOX_EXPORT NamespaceSandbox {
+ public:
+  NamespaceSandbox();
+  ~NamespaceSandbox();
+
+  // Setup the launch options for the sandboxed process. The caller is
+  // responsible for setting options->fds_to_remap = fds_to_remap.
+  void SetupLaunchOptions(base::LaunchOptions* options,

[jln (very slow on Chromium), 2015/01/28 02:34:39]

Maybe mention again that CanCreateProcessInNewUserNS must be true?

[jln (very slow on Chromium), 2015/01/28 02:34:39]

We should at least claim ownership of options. That's because we own the
PreExecDelegate, and both should be tied.

- You could take a scoped_ptr<LaunchOptions> here, which would guarantee that
the caller is doing the right thing, and it would make it clear that we're
taking ownership.
- We could simply take a LaunchOptions instead of a pointer and hold that copy a
a NamespaceSandbox member.

In this case, we should provide our own LaunchProcess() wrapper here, which
could also help us remove the explicit PrepareSandboxedProcess() step.

[rickyz (no longer on Chrome), 2015/01/29 00:57:48]

For now, I went with embedding the LaunchOptions in NamespaceSandbox. As things
are now, passing a scoped_ptr is a little deceptive because LaunchOptions may
contain pointers to outside objects. This API still isn't ideal - I currently
expose a mutable_launch_options where users may still set pointer fields (though
lifetime requirements are documented at least) because the nacl zygote code will
eventually need it.

Eventually, it might be worth changing LaunchOptions to avoid having so many
pointers to lists and such, but then pre_exec_delegate would still be
problematic, blech. Will think more about what kind of change I'd make to
LaunchOptions, but here's kind of a compromise for now.

[rickyz (no longer on Chrome), 2015/01/29 01:02:48]

Oops, missed this one, added a comment to Launch.

+                          base::FileHandleMappingVector* fds_to_remap);
+
+  // Prepares the child process before it execs the new program. This adds an
+  // identity mapping for the uid and gid inside the user namespace, then
+  // signals the child to exec the new program.
+  void PrepareSandboxedProcess(base::ProcessId pid);
+
+  // 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:
+  class ReadFromPipeDelegate : public base::LaunchOptions::PreExecDelegate {

[jln (very slow on Chromium), 2015/01/28 02:34:39]

It's an edge case, but I would split to its own file for clarity.

[rickyz (no longer on Chrome), 2015/01/29 00:57:48]

This became unnecessary after the last refactoring.

+   public:
+    ReadFromPipeDelegate();
+    ~ReadFromPipeDelegate() override;
+    void RunAsyncSafe() override;
+    void set_fd(int fd);
+
+   private:
+    int fd_;

[jln (very slow on Chromium), 2015/01/28 02:34:39]

ReadFromPipeDelegate should own this file descriptor. Let's make this a
ScopedFD.

[rickyz (no longer on Chrome), 2015/01/29 00:57:48]

I didn't want to make the delegate own the fd because ownership across fork
isn't so obvious. If this were a ScopedFd, then we would still need to
explicitly close the fd in the child because the delegate will never be
destroyed (since we'll execve).

+    DISALLOW_COPY_AND_ASSIGN(ReadFromPipeDelegate);
+  };
+  // Pipe fds used to communicate with the child process.
+  base::ScopedFD read_fd_;
+  base::ScopedFD write_fd_;
+
+  ReadFromPipeDelegate read_from_pipe_delegate_;
+};
+
+}  // namespace sandbox
+
+#endif  // SANDBOX_LINUX_SERVICES_NAMESPACE_SANDBOX_H_