Initial implementation of the Mac Bootstrap Sandbox.

sandbox/mac/bootstrap_sandbox.h

+// Copyright 2014 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_MAC_BOOTSTRAP_SANDBOX_H_
+#define SANDBOX_MAC_BOOTSTRAP_SANDBOX_H_
+
+#include <mach/mach.h>
+
+#include <map>
+#include <string>
+
+#include "base/memory/scoped_ptr.h"
+#include "base/process/process_handle.h"
+#include "base/synchronization/lock.h"
+#include "sandbox/mac/policy.h"
+
+namespace sandbox {
+
+class LaunchdInterceptionServer;
+
+// The BootstrapSandbox is a second-layer sandbox for Mac. It is used to limit
+// the bootstrap namespace attack surface of child processes. The parent
+// process creates an instance of this class and registers policies that it
+// can enforce on its children.
+//
+// With this sandbox, the bootstrap port of the parent process is replaced, so
+// that child processes is taken over by the sandbox. Bootstrap messages from
+// the parent are forwarded to launchd. Requests from the child that would
+// normally go to launchd are filtered based on the specified per-process
+// policies. If a request is permitted by the policy, it is forwarded on to
+// launchd for servicing. If it is not, then the sandbox will reply with a
+// primitive that does not grant additional capabilities to the receiver.
+//
+// When the parent is ready to fork a new child process with this sandbox
+// being enforced, it should use the pair of methods PrepareToForkWithPolicy()
+// and FinishedFork(), and call fork() between them. The first method will
+// set the policy for the new process, and the second will finialize the
+// association between the process ID and sandbox policy ID.
+//
+// All methods of this class may be called from any thread, but
+// PrepareToForkWithPolicy() and FinishedFork() must be non-nested and balanced.

[Mark Mentovai, 2014/05/06 20:51:50]

An alternative would be to make PrepareToForkWithPolicy return some handle that
the caller would need to supply to FinishedFork, to not limit the nestiness and
balanciness of things.

[Robert Sesek, 2014/05/08 20:58:12]

I need to limit the nestiness and balanciness of things because you don't know
what policy to apply if there are multiple simultaneous sandbox fork()s, until
the PID is associated with a policy. And the child can and does start executing
sometime in that window (base::LaunchProcess handles both the fork and the
exec), making bootstrap requests.

+class BootstrapSandbox {
+ public:
+  // Creates a new sandbox manager. Returns NULL on failure.

[Mark Mentovai, 2014/05/06 20:51:50]

Isn’t it more normal to have a constructor and, for initialization work that can
fail, an Initialize method?

[Robert Sesek, 2014/05/08 20:58:12]

They're both acceptable in Chromium. I generally prefer this for public
interfaces because it doesn't mean you can have an object in an inconsistent
state.

+  static scoped_ptr<BootstrapSandbox> Create();
+
+  ~BootstrapSandbox();
+
+  // Registers a bootstrap policy associated it with an identifier. The
+  // |sandbox_policy_id| must be greater than 0.
+  void RegisterSandboxPolicy(int sandbox_policy_id,

[Mark Mentovai, 2014/05/06 20:51:50]

This requires callers to come up with fixed and unique IDs, in addition to
supplying the policy object? That seems a unnecessary. Why not have this
function return the policy ID to the caller as an opaque handle kind of type?

[Robert Sesek, 2014/05/08 20:58:12]

Yes, I chose this because we already have sandbox-type enums that we will likely
want to re-use.

+                             const BootstrapSandboxPolicy& policy);
+
+  // Called in the parent prior to fork()ing a child. The policy registered

[Mark Mentovai, 2014/05/06 20:51:50]

The comments on this function and the two that follow say “called in the
parent” which doesn’t make it clear that the client code is supposed to call
this. It could also mean that your sandbox calls these functions.

[Robert Sesek, 2014/05/08 20:58:12]

Clarified this in the class-level comment.

+  // to |sandbox_policy_id| will be enforced on the new child. Returns true
+  // on success and false if the policy does not exist.
+  bool PrepareToForkWithPolicy(int sandbox_policy_id);
+  // Called in the parent after fork()ing a child. It records the |handle|

[Mark Mentovai, 2014/05/06 20:51:50]

Blank line before, otherwise PrepareToForkWithPolicy gets lost.

[Robert Sesek, 2014/05/08 20:58:12]

Done.

+  // and associates it with the specified-above |sandbox_policy_id|.

[Mark Mentovai, 2014/05/06 20:51:50]

What’s the caller supposed to do if they call PrepareToForkWithPolicy and then
fork, but the fork fails?

[Robert Sesek, 2014/05/08 20:58:12]

Done.

+  void FinishedFork(base::ProcessHandle handle);
+
+  // Called in the parent when a process has died. It cleans up the references
+  // to the process.
+  void ChildDied(base::ProcessHandle handle);
+
+  // Looks up the policy for a given process ID. If no policy is associated
+  // with the |pid|, this returns NULL.
+  const BootstrapSandboxPolicy* PolicyForProcess(pid_t pid) const;
+
+  mach_port_t real_bootstrap_port() const { return real_bootstrap_port_; }
+
+ private:
+  BootstrapSandbox();
+
+  // A Mach IPC message server that is used to intercept and filter bootstrap
+  // requests.
+  scoped_ptr<LaunchdInterceptionServer> server_;
+
+  // The original bootstrap port of the process, which is connected to the
+  // real launchd server.
+  mach_port_t real_bootstrap_port_;
+
+  // The |lock_| protects all proceeding variables.

[Mark Mentovai, 2014/05/06 20:51:50]

It’s spelled preceding, but the comment is wrong, because the lock is protecting
all following variables.

[Robert Sesek, 2014/05/08 20:58:12]

Done.

+  mutable base::Lock lock_;
+
+  // Used to track if multiple threads are trying to fork() with the sandbox
+  // simultaneously.
+  bool is_across_fork_;

[Mark Mentovai, 2014/05/06 20:51:50]

Blank line after this.

[Mark Mentovai, 2014/05/06 20:51:50]

A better name would be prepared_to_fork_—something that makes clearer that
PrepareToForkWithPolicy was called but FinishedFork wasn’t.

[Robert Sesek, 2014/05/08 20:58:12]

Done.

[Robert Sesek, 2014/05/08 20:58:12]

Removed, see other comment.

+  // The sandbox_policy_id that will be enforced for the new child.
+  int effective_policy_id_;
+
+  // All the policies that have been registered with this sandbox manager.
+  std::map<int, const BootstrapSandboxPolicy> policies_;
+
+  // The association between process ID and sandbox policy ID.
+  std::map<base::ProcessHandle, int> sandboxed_processes_;
+};
+
+}  // namespace content
+
+#endif  // SANDBOX_MAC_BOOTSTRAP_SANDBOX_H_