Simon McVittie

The three most promising routes forward that I can see all require coordination with other packages: * https://github.com/containers/bubblewrap/pull/452, and then depend on that version of bubblewrap, and use it in...

Yes, in an ideal world we'd use all three of the solutions I mentioned.

> I wonder if we should also pre-compute the selinux rules seccomp rules, do you mean? I don't think that works: they're architecture-specific. We'd have to precompute a rules blob...

> Why are you trying to avoid depending on libseccomp? Depending on libseccomp is fine, the problem is being able to depend on *modern* libseccomp. For example, Debian 10 has...

> Maybe we could vendor a recent version [of libseccomp] I think that's a non-starter. If distributions don't want to backport libseccomp itself, then they are *absolutely* not going to...

Rebased, with a submodule update to pick up containers/bubblewrap#459. This is not suitable to be merged as-is, because for users of a system copy of bubblewrap, it requires a version...

> Not tested on ye olde OSs yet I've now successfully tested this on Ubuntu 18.04 (with an unrelated test failure in `tests/test-history.sh` that I haven't investigated yet), Debian 10...

Now that we have bubblewrap 0.6.1, I'd like to consider this for Flatpak 1.13.x. The benefit of this is that if a new kernel with new and exciting syscalls triggers...

Any chance someone could review this, https://github.com/containers/bubblewrap/pull/488 and/or https://github.com/containers/bubblewrap/pull/452? I'd be more comfortable about Flatpak's resilience against vulnerabilities like CVE-2021-41133 if we could get one of those into 1.14.x.

This change is less important than it used to be, now that we have `--disable-userns`, which would have prevented CVE-2021-41133 in a different way. However, using an allowlist instead of...