andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 1 | # seccomp Sandbox Crash Dumping |
| 2 | |
| 3 | Currently, Breakpad relies on facilities that are disallowed inside the Linux |
| 4 | seccomp sandbox. Specifically, it sets a signal handler to catch faults |
| 5 | (currently disallowed), forks a new process, and uses ptrace() (also disallowed) |
| 6 | to read the memory of the faulted process. |
andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 7 | |
| 8 | ## Options |
andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 9 | |
andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 10 | There are three ways we could do crash dumping of seccomp-sandboxed processes: |
andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 11 | |
| 12 | * Find a way to permit signal handling safely inside the sandbox (see below). |
| 13 | * Allow the kernel's core dumper to kick in and write a core file. |
| 14 | * This seems risky because this code tends not to be well-tested. |
| 15 | * This will not work if the process is chrooted, so it would not work if |
| 16 | the seccomp sandbox is stacked with the SUID sandbox. |
| 17 | * Have an unsandboxed helper process which `ptrace()`s the sandboxed process |
| 18 | to catch faults. |
andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 19 | |
| 20 | ## Signal handling in the seccomp sandbox |
andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 21 | |
| 22 | In case a trusted thread faults with a SIGSEGV, we must make sure that an |
| 23 | untrusted thread cannot register a signal handler that will run in the context |
| 24 | of the trusted thread. |
andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 25 | |
| 26 | Here are some mechanisms that could make this safe: |
andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 27 | |
| 28 | * `sigaltstack()` is per-thread. If we opt not to set a signal stack for |
| 29 | trusted threads, and set %esp/%rsp to an invalid address, trusted threads |
| 30 | will die safely if they fault. |
| 31 | * This means the trusted thread cannot set a signal stack on behalf of the |
| 32 | untrusted thread once the latter has switched to seccomp mode. The |
| 33 | signal stack would have to be set up when the thread is created and not |
| 34 | subsequently changed. |
| 35 | * `clone()` has a `CLONE_SIGHAND` flag. By omitting this flag, trusted and |
| 36 | untrusted threads can have different sets of signal handlers. This means we |
| 37 | can opt not to set signal handlers for trusted threads. |
| 38 | * Again, per-thread signal handler sets would mean the trusted thread |
| 39 | cannot change signal handlers on behalf of untrusted threads. |
| 40 | * `sigprocmask()/pthread_sigmask()`: These can be used to block signal |
| 41 | handling in trusted threads. |
andybons | 3322f76 | 2015-08-24 21:37:09 | [diff] [blame] | 42 | |
| 43 | ## See also |
andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 44 | |
Tom Anderson | 93e49e49 | 2019-12-23 19:55:37 | [diff] [blame] | 45 | * [LinuxCrashDumping](linux/crash_dumping.md) |
andybons | ad92aa3 | 2015-08-31 02:27:44 | [diff] [blame] | 46 | * [Issue 37728](https://crbug.com/37728) |