Report suspected vulnerabilities privately to security@necessary.nu, rather than in a public issue.
Please read the rest of this document first. The most common report is that a
sandbox built with a particular set of arguments does not contain the process
inside it — which, as described below, usually means those arguments do not
express the security model the caller wanted, not that sandbox has a
vulnerability.
sandbox is not a security boundary between the user and the OS,
because anything sandbox could do, a malicious user could equally
well do by writing their own equivalent tool.
There is no setuid mode: the binary refuses to operate if it has been made setuid.
sandbox is a toolkit for constructing sandbox environments.
sandbox is not a complete, ready-made sandbox with a specific security
policy.
Some use-cases want a security boundary between the sandbox
and the real system; other use-cases want the ability to change the layout of
the filesystem for processes inside the sandbox, but do not aim to be a
security boundary.
As a result, the level of protection between the sandboxed processes and
the host system is entirely determined by the arguments passed to
sandbox.
Whatever program constructs the command-line arguments for sandbox
(a larger framework, or an ad-hoc script) is responsible for defining its own
security model, and choosing appropriate sandbox command-line arguments to
implement that security model.
For example,
CVE-2017-5226
(in which a Flatpak app could send input to a parent terminal using the
TIOCSTI ioctl) was considered to be a Flatpak vulnerability, not a
vulnerability in the sandboxing tool it called.