Start all children in their own PID namespace.

content/zygote/zygote_main_linux.cc

Index: content/zygote/zygote_main_linux.cc
diff --git a/content/zygote/zygote_main_linux.cc b/content/zygote/zygote_main_linux.cc
index d1bd8cc076f44cef02f51a3033507e49a43b722e..c0c0ad1acf467b09832f7015f3a2b36e41a966cb 100644
--- a/content/zygote/zygote_main_linux.cc
+++ b/content/zygote/zygote_main_linux.cc
@@ -465,7 +465,8 @@ static void EnterNamespaceSandbox(base::Closure* post_fork_parent_callback) {
 
   CHECK(sandbox::Credentials::MoveToNewUserNS());
   CHECK(sandbox::Credentials::DropFileSystemAccess());
-  CHECK(sandbox::Credentials::DropAllCapabilities());

[rickyz (no longer on Chrome), 2015/02/07 05:14:03]

Like I mentioned in that last change, we need CAP_SYS_ADMIN in order to start
children in their own PID namespaces. We should probably discuss whether the
gains of isolating renderers is worth the additional attack surface of the
syscalls exposed by these capabilities on the zygote.

[mdempsky, 2015/02/09 06:28:12]

Couple thoughts I have:

  1. Would it be worthwhile to drop everything else except for CAP_SYS_ADMIN if
that's all we need?  (Do we even have other capabilities?)
  2. I think the init process reaper now will have unneeded capabilities too;
that's probably not a risk, but might as well drop the capabilities there too so
only the actual zygote process needs to reap?

[rickyz (no longer on Chrome), 2015/02/24 06:11:34]

Done - I didn't look too much into how much attack surface this takes away -
CAP_SYS_ADMIN seems to be used as a catch-all in a lot of places.
Done.

+  // We do not drop capabilities because we will use CAP_SYS_ADMIN to place each
+  // child process in its own PID namespace later on.
 
   // This needs to happen after moving to a new user NS, since doing so involves
   // writing the UID/GID map.