Zygote: Initialize NSS fully

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 4cd81054c2528318103d7ca0b8f257ccf2509c17..b52ea45c4931198a33e0384dd1c394fba9e0e316 100644
--- a/content/zygote/zygote_main_linux.cc
+++ b/content/zygote/zygote_main_linux.cc
@@ -490,6 +490,24 @@ bool ZygoteMain(const MainFunctionParams& params,
 
   int sandbox_flags = linux_sandbox->GetStatus();
 
+#if defined(USE_NSS)
+  // Do some extra NSS initialization. We don't want to do this pre-sandbox

[wtc, 2012/10/23 18:52:28]

Nit: change "Do some extra NSS initialization" to
"Initialize NSS". The word "extra" seems to imply an
incremental initialization, but crypto::EnsureNSSInit()
fully initializes NSS.

[jln (very slow on Chromium), 2012/10/23 19:06:50]

Done.

+  // because it's not well defined what venues of attacks it could create.
+  //
+  // In addition to the benfit of doing this initialization only once, (it
+  // will be inherited), this is a good warm-up before we enable our next layer
+  // of sandbox, e.g. seccomp-bpf.

[wtc, 2012/10/23 18:52:28]

In general a multithreaded program on Unix should avoid
forking without doing exec*(). I guess zygote calls fork()
without calling exec*()?

[jln (very slow on Chromium), 2012/10/23 19:06:50]

Yes, but we don't have threads at this point. If we had thread, it would be a
major issue.

+
+  // We will soon fork, but we haven't loaded any security module.
+  crypto::DisableNSSForkCheck();

[wtc, 2012/10/23 18:52:28]

I am not familiar with what it takes to make NSS work correctly
across a fork() call. I remember it is supported, with two
modes (the "PKCS #11 compliant" mode which does the fork
check and the original mode). I would avoid initializing NSS
before forking.

Here is a NSS bug query for all bugs that mention "fork" in
the summary:
https://bugzilla.mozilla.org/buglist.cgi?list_id=4755732;short_desc_type=allw...

[jln (very slow on Chromium), 2012/10/23 19:06:50]

I think that is the most important part. If you and Ryan can't be comfortable
with this, then unfortunately we should switch to a model where we initialize
NSS in the renderer / PPAPI process, but before we enable the sandbox.

+  // The setuid sandbox would prevent opening user security modules anyway,
+  // but it's more correct to tell NSS to not do it.
+  // Loading user security modules would have security implications.
+  crypto::ForceNSSNoDBInit();
+  // Initialize NSS, every child process will benefit from it.
+  crypto::EnsureNSSInit();
+#endif
+
   Zygote zygote(sandbox_flags, forkdelegate);
   // This function call can return multiple times, once per fork().
   return zygote.ProcessRequests();