containers
Consider adding optional pre-configure seccomp filters
SECURITY.md clarifies that it is not the task of bwrap to enure that a real security barrier is created.
However, as I understand it, there is a list of seccomp rules that are fundamental to ensuring that bwrap can function as a sandbox at all. For example: unshare, setns, or mount.
I originally wasn't in favor of adding this to bwrap, and thought we could put it into a library that uses bwrap. But now I think if we can find a good set or good multiple sets, we should add them.
The issue currently is that there are too many consumers that have to create seccomp rules for this themselves, and this is very prone to errors.
First step would be to have a table which lists what seccomp rules are needed and when. Sadly, even Flatpak etc don't properly document their seccomp rules.
However, as I understand it, there is a list of seccomp rules that are fundamental to ensuring that bwrap can function as a sandbox at all. For example: unshare, setns, or mount.
It's more complicated than that.
Flatpak needs to forbid creation of a nested userns because that would break Flatpak's security model. Flatpak's security model relies on components like xdg-desktop-portal being able to identify a sandboxed process by it having /proc/$pid/root/.flatpak-info, and that security property would not be available if the sandboxed process was able to manipulate its filesystem namespace.
The same applies to processes that are identifying themselves to x-d-p by pretending that they are Flatpak apps when they are really not (but ideally nobody should have to do that, and there should be some other way to mark a process as not being part of the TCB, because everyone pretending to be Flatpak scales poorly).
However, it is not the case that forbidding these syscalls is a requirement for bwrap being a meaningful sandbox in general. If the security model that the bwrap user is imposing is not the same as Flatpak's, then things that need to be forbidden for Flatpak's security model to work do not necessarily need to be forbidden.
A concrete example is that if you're doing a tightly sandboxed helper process like an image loader or thumbnailer (which I think is your use-case?), and it doesn't have access to portals or other host services via D-Bus, Wayland or other socket-based protocols, then it doesn't actually matter whether it can create a nested userns or not, because nobody is going to be making trust decisions based on inspection of its /proc/$pid/root/.flatpak-info anyway.
For security models where preventing userns creation is required, it is also not necessarily the case that these syscalls need to be forbidden by seccomp specifically. Recent versions of bwrap have bwrap --disable-userns, which forbids creation of a nested userns via the user.max_user_namespaces sysctl instead, and bwrap --userns FD --assert-userns-disabled, which verifies that some other process has already prevented the userns that we're entering from creating an additional nested userns.
I originally wasn't in favor of adding this to bwrap, and thought we could put it into a library that uses bwrap. But now I think if we can find a good set or good multiple sets, we should add them.
There is a practical problem with this: bwrap is (still) sometimes setuid root, and even on systems where it does not need to be setuid root any more (the majority), "it's OK to make bwrap setuid root" is now part of sysadmin/distro/tinkerer folklore. This means that each dependency we add to it is extra attack surface that might result in a root privilege escalation vulnerability.
libseccomp would be extra attack surface, and any library we used to make higher complexity less error-prone (for example GLib) would be a lot of extra attack surface. This is why we can't have nice things.