58 lines
2.4 KiB
ReStructuredText
58 lines
2.4 KiB
ReStructuredText
Profiling Sandbox violations (Linux)
|
|
====================================
|
|
|
|
Recoding sandbox violations
|
|
---------------------------
|
|
|
|
The profiler now offers a way to track sandbox violations happening from child
|
|
processes on Linux systems. One can also rely on `MOZ_PROFILER_STARTUP=1`.
|
|
Please make sure you select the `Debug` preset and that you enable the
|
|
`Sandbox` feature. If you make use of a different preset, make sure the threads
|
|
list includes `SandboxProfilerEmitter` to capture both threads.
|
|
|
|
It will record sandbox requests (child process system calls intercepted) as
|
|
well as audit (deny decision, whether the sandbox is running in permissive mode
|
|
or not). This should also record `SANDBOX_LOG` statements, including the policy
|
|
if the process is started when the profiler is running.
|
|
|
|
We manage to capture the call stack on the child process and pass that to the
|
|
profiler, so hopefully any thread in our child process will report a stack
|
|
explaining why the syscall was made.
|
|
|
|
Capturing the stack might require either a nightly build (opt or debug), or a
|
|
beta/release build with debug enabled.
|
|
|
|
We report markers on the `SandboxProfilerEmitterSyscalls` thread for syscalls
|
|
and `SandboxProfilerEmitterLogs` for `SANDBOX_LOG` entries.
|
|
|
|
Analyzing data
|
|
--------------
|
|
|
|
The sandbox on Linux works by intercepting child processes system calls, and
|
|
via a communication channel to the parent process, decide whether we allow or
|
|
not, and maybe perform brokering.
|
|
|
|
Because we generate data on the child and on the parent process, there is a
|
|
pairing system in place: each child process is going to wrap an identifier (an
|
|
int) within its sandbox requests, that will be visible on the markers table of
|
|
that child. Parent process will have an `FSBrokerXXX` thread for each child
|
|
process (where `XXX` is the PID of the child), and attached markers for
|
|
permissive or denial audit.
|
|
|
|
One should select one or all of the `SandboxProfilerEmitterSyscalls` or
|
|
`SandboxProfilerEmitterLogs` thread(s) on child process(es), and matching
|
|
`FSBrokerXXX` thread(s) on the parent process. Then it is just a matter, within
|
|
the correct pair of child/parent threads, to match requests IDs with audit IDs
|
|
to uncover the valuable information.
|
|
|
|
Those would include, on the child side:
|
|
- PID;
|
|
- syscall name;
|
|
- syscall flags;
|
|
- path parameters when some;
|
|
|
|
And on the parent side in case of denial,
|
|
- Child PID;
|
|
- syscall name;
|
|
- syscall flags;
|
|
- permissions;
|