sandbox.rst - mozsearch

Enable keyboard shortcuts

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;