Zygote: Initialize NSS fully

content/zygote/zygote_main_linux.cc

 // Copyright (c) 2012 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.
 
 #include <dlfcn.h>
 #include <fcntl.h>
 #include <pthread.h>
 #include <stdio.h>
 #include <sys/socket.h>
 #include <sys/stat.h>
@@ skipping 472 matching lines @@
   }
 
   if (setuid_sandbox->IsInNewPIDNamespace() && !has_started_new_init) {
     LOG(ERROR) << "The SUID sandbox created a new PID namespace but Zygote "
                   "is not the init process. Please, make sure the SUID "
                   "binary is up to date.";
   }
 
   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();
 }
 
 }  // namespace content