Enable one PID namespace per process for NaCl processes.

components/nacl/loader/nonsfi/irt_exception_handling.cc

 // 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.
 
 #include <errno.h>
 #include <pthread.h>
 #include <signal.h>
 
 #include "components/nacl/loader/nonsfi/irt_interfaces.h"
 #include "native_client/src/include/nacl_macros.h"
@@ skipping 11 matching lines @@
 // native_client/src/trusted/service_runtime/sys_exception.c
 
 // Crash signals to handle.  The differences from SFI NaCl are that
 // NonSFI NaCl does not use NACL_THREAD_SUSPEND_SIGNAL (==SIGUSR1),
 // and SIGSYS is reserved for seccomp-bpf.
 const int kSignals[] = {
 #if !defined(__mips__)
   // This signal does not exist on MIPS.
   SIGSTKFLT,
 #endif
-  SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGBUS, SIGFPE, SIGSEGV,
+  SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGBUS, SIGFPE, SIGSEGV, SIGTERM,

[Mark Seaborn, 2015/06/10 18:53:12]

Do you need to add SIGHUP and SIGTERM, or is it just for consistency?

The original purpose of this list is just for synchronous hardware exceptions
that we want to pass on to the app.  So SIGINT didn't need to be here, though it
doesn't really hurt to have async signals here.

If you need SIGHUP/SIGTERM, you might want to add them to the newlib-based
implementation in native_client/src/nonsfi/linux/irt_exception_handling.c, which
is slated to replace components/nacl/loader/nonsfi/irt_exception_handling.cc.

[rickyz (no longer on Chrome), 2015/06/10 22:42:34]

I want to add any signals that might be sent to the process in an attempt to
terminate it. When the NaCl loader is the init process in a pid namespace, Linux
drops signals other than SIGSTOP and SIGKILL unless the process has an explicit
signal handler set, which is why I want to make sure that there is a signal
handler which will terminate the process by default.

Will send a change for the replacement in native_client once I get a better
grasp of what the correct change is :-)

   // Handle SIGABRT in case someone sends it asynchronously using kill().
   SIGABRT
 };
 
 pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
 NaClExceptionHandler signal_handler_function_pointer = NULL;
 
 // Signal handler, responsible for calling the registered handler.
 void SignalCatch(int sig, siginfo_t* info, void* uc) {
   if (signal_handler_function_pointer) {
     NaClSignalContext signal_context;
     NaClSignalContextFromHandler(&signal_context, uc);
     NaClExceptionFrame exception_frame;
     NaClSignalSetUpExceptionFrame(&exception_frame,
                                   &signal_context,
                                   0 /* context_user_addr,
                                        not useful for NonSFI NaCl. */);
     signal_handler_function_pointer(&exception_frame.context);
   }
-  _exit(-1);
+  _exit(-sig);

[rickyz (no longer on Chrome), 2015/06/10 01:31:43]

I didn't want to change this file a ton in this CL, but the behavior of
SignalCatch looks a little weird here - I don't see how
signal_handler_function_pointer ever gets the signal number, and the signal
handler unconditionally exits with no apparent way to tell whether it was
handled with a custom handler or not.

[Mark Seaborn, 2015/06/10 18:53:12]

Yes, that's all intentional.

This implements the NaCl IRT interface for handling hardware exceptions, defined
here:
https://chromium.googlesource.com/native_client/src/native_client/+/master/sr...

This interface currently doesn't report the type of hardware exception.  It also
doesn't support returning from the exception handler (though you can longjmp()
out).

[rickyz (no longer on Chrome), 2015/06/10 22:42:34]

Ah, in that case, is it incorrect to run the exception handler on
SIGINT/SIGHUP/SIGTERM? Also, out of curiosity, is there a real need for the
hardware exception interface on non-SFI? It wouldn't make things any less safe
to let non-SFI programs set whatever signal handlers they want, right?

[Mark Seaborn, 2015/06/15 22:29:04]

Yes, it's technically incorrect, although it might not matter in practice.

If having handlers for SIGINT/SIGHUP/SIGTERM is required by the sandbox code, it
would be better to have the sandbox layer register those handlers, mostly for
the sake of clarity.
It depends what level you're asking about:
 * the security of Non-SFI NaCl's Linux sandbox
 * the definition of Non-SFI NaCl's stable ABI

For security: We currently disable the sigaction() syscall in the seccomp-bpf
sandbox.  We could allow it.  It's *probably* safe.  But we don't need to allow
it, because we can pre-register a handler and have it forward.  So as general
attack surface reduction, we disable sigaction().

For the ABI definition: The interface that user programs are meant to use is
*not* Linux syscalls.  Non-SFI NaCl provides IRT interfaces instead (roughly the
same interfaces as what SFI NaCl provides).  We don't want to support the full
generality of what Linux signals can do.

[rickyz (no longer on Chrome), 2015/06/15 23:23:51]

Ah, thank you for the detailed explanation. In that case, I've switched to
installing termination signal handlers in the nacl helper for nonsfi mode. For
SFI mode, I'll leave the signal handlers to NaCl since the segments/signal stack
stuff is tricky and security-sensitive.

 }
 
 int IrtExceptionHandler(NaClExceptionHandler handler,
                                NaClExceptionHandler* old_handler) {
   pthread_mutex_lock(&mutex);
   if (old_handler)
     *old_handler = signal_handler_function_pointer;
   signal_handler_function_pointer = handler;
   pthread_mutex_unlock(&mutex);
   return 0;
@@ skipping 38 matching lines @@
 
   // Install all handlers.
   for (a = 0; a < NACL_ARRAY_SIZE(kSignals); a++) {
     if (sigaction(kSignals[a], &sa, NULL) != 0)
       NaClLog(LOG_FATAL, "sigaction to register signals failed.\n");
   }
 }
 
 }  // namespace nonsfi
 }  // namespace nacl