39
edits
(→Use in Gecko: Update for bug 1055310) |
|||
Line 69: | Line 69: | ||
* Sandbox.h: the public interface; used when a child process is ready to enter sandboxed mode | * Sandbox.h: the public interface; used when a child process is ready to enter sandboxed mode | ||
* SandboxFilter.cpp: the sandbox policy definitions | * SandboxFilter.cpp: the sandbox policy definitions, and trap handlers for intercepted syscalls | ||
* Sandbox.cpp: the code that starts the sandbox and handles violations | |||
* Sandbox.cpp: the code that starts the sandbox and handles violations | |||
The policy is compiled into a seccomp-bpf program using the Chromium code imported in security/sandbox/chromium/sandbox/linux. Files of interest in that subtree: | |||
* bpf_dsl/bpf_dsl.h: defines the interface used to specify the policy | |||
* bpf_dsl/policy_compiler.cc: converts the intermediate form into BPF instructions | |||
* services/arm_linux_syscalls.h and other *_linux_syscalls.h: syscall number definitions; grep these to translate syscall numbers seen in error messages (use the file corresponding to the architecture in question) | |||
=== Seccomp reporter === | === Seccomp reporter === | ||
Line 82: | Line 84: | ||
seccomp sandbox violation: pid %u, syscall %lu, args %lu %lu %lu %lu %lu. Killing Process. | seccomp sandbox violation: pid %u, syscall %lu, args %lu %lu %lu %lu %lu. Killing Process. | ||
Note that the SIGSYS handler is also used for syscalls that we want to intercept and “polyfill” with some other action; in that case it modifies the signal context and returns, instead of crashing. | |||
=== How do I check my processes are sandboxed by seccomp? === | === How do I check my processes are sandboxed by seccomp? === |
edits