Security/Sandbox/Seccomp: Difference between revisions

Security/Sandbox/Seccomp (view source)

Revision as of 01:55, 26 August 2014

889 bytes added , 26 August 2014

→‎Use in Gecko

JLD

39

edits

@@ Line 66: / Line 66: @@
 == Use in Gecko ==
-Gecko on the desktop and in B2G use seccomp when running on Linux.
+The code is in mozilla-central at security/sandbox/linux.  Files of interest:
-The code is in mozilla-central at /security/sandbox/linux.
-'''File''' security/sandbox/linux/seccomp_filter.h
+* Sandbox.h: the public interface; used when a child process is ready to enter sandboxed mode
+* SandboxFilter.cpp: the sandbox policy definitions
+* SandboxAssembler.{h,cpp}: implements the policies in terms of the Chromium CodeGen module
+* Sandbox.cpp: the code that starts the sandbox and handles violations (note: this is changing soon; see {{bug|1041886}}).
+* {arm,x86_{32,64}}_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)
-Contains a whitelist of allowed system calls.
+We also have an import of the Chromium seccomp-bpf libraries at security/sandbox/chromium/sandbox/linux/seccomp-bpf; we're currently using the CodeGen/BasicBlock/Instruction layer, but not ErrorCode or SandboxBPF (yet).
-'''File''' security/sandbox/linux/Sandbox.cpp
-Contains the sandbox installation code, called by:
-  SetCurrentProcessSandbox(void)
 === Seccomp reporter ===
-The reporter is an option which will log exactly which system call has been denied by seccomp. It is enabled by default in engineering builds ("eng" builds).
+When seccomp denies a system call, it sends a signal (SIGSYS) which is handled by the reporter.  The reporter logs information about the syscall, invokes the crash reporter, tries to log the current JS stack if any, and finally terminates the process.
-The option is --content-sandbox-reporter.
-When seccomp denies a system call, it sends a signal (SIGSYS) which is caught by the reporter. The reporter then kills itself (and thus the content-process).
-The report kill itself because the content process may not handle the denied system call properly and be in a non-working state anyway.
-When the reporter is enabled, the log message looks like this:
+The log message looks like this:
    seccomp sandbox violation: pid %u, syscall %lu, args %lu %lu %lu %lu %lu. Killing Process.
 === How do I check my processes are sandboxed by seccomp? ===
-There is a seccomp flag in the process status:
+There is a seccomp flag in the process status.  Use this command, replacing <pid> with the process's PID:
-Replace <pid> by the process's PID.
    grep Seccomp /proc/<pid>/status
 * 0: Seccomp is not enabled (bad!)
-* 1: Seccomp is enabled (shouldn't happen)
+* 1: Seccomp "strict mode" is enabled (shouldn't happen)
 * 2: Seccomp-bpf is enabled (correct)
@@ Line 108: / Line 99: @@
 === How do I disable the sandbox temporarily? ===
+For content process ([[Electrolysis|e10s]], B2G) sandboxing:
    export MOZ_DISABLE_CONTENT_SANDBOX=1
@@ Line 117: / Line 110: @@
    export MOZ_DISABLE_CONTENT_SANDBOX=1
    /system/bin/b2g.sh
+For Gecko Media Plugin sandboxing on desktop (OpenH264, EME, etc.):
+  export MOZ_DISABLE_GMP_SANDBOX=1
+Also, to simulate the effect of having no sandbox support in the kernel:
+  export MOZ_FAKE_NO_SANDBOX=1
+In particular, this will disable media plugin support on desktop, and cause B2G based on Android KitKat or later to completely refuse to start, unless the corresponding DISABLE option is set — which is the intended behavior if sandboxing isn't possible in those cases.   This is probably not useful except to test that kind of mandatory-sandboxing feature.
 == More information ==