Fallout from dlopen() blocking SIGSYS

[Jed Davis]

On Thu, Dec 5, 2019 at 2:47 AM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
> I saw this fly by the libc-alpha mailing list late at night yesterday. I
> think with work we've recently done in the upstream kernel the
> SECCOMP_RET_TRAP approach trapping and signaling is not needed anymore
> at least on newer kernels. That won't help you with legacy but it's
> still worth considering switching over.

Thank you for that detailed writeup.  SECCOMP_RET_USER_NOTIF does seem
to be capable of doing everything we're currently doing with
SECCOMP_RET_TRAP, and it should be feasible to use SECCOMP_RET_TRAP to
implement similar functionality for the case of old kernel +
SIGSYS-tolerant userland to avoid excessive code duplication.  It is
going to cause some extra context switches (anything like open() that
needs to pass back fds, and anything that's currently handled
in-process), but this was never meant to be on a critical path.  There
may also be problems with external security policies, like the Snap
package manager's confinement, that try to restrict ptrace-like
actions.  And, of course, rewriting everything will be a nontrivial
project.

Also, if Firefox needs to be SIGSYS-free before 2020-09-22, when the
68.x extended support branch ends, then we need to somehow find a
“low-risk” way to implement this major change.

As for legacy support: normally we can't rely on new kernel features
like that (even SECCOMP_FILTER_FLAG_TSYNC is still too new to use
without a fallback), but in this case there would have to be an older
kernel combined with a significantly newer glibc (whichever version
eventually unrecoverably breaks the use of SIGSYS) to have problems,
so this is hopefully an exception.

--Jed