Fallout from dlopen() blocking SIGSYS

[Christian Brauner]

On Fri, Dec 06, 2019 at 05:09:17PM -0700, Jed Davis wrote:
> 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

Hm, I'd need more details about this specific worry. The notifier itself
doesn't need any ptrace-like capabilities. Only if you want to
get/inject/replace file descriptors. But if that's a feature you need we
can implement this directly in the notifier.

> actions.  And, of course, rewriting everything will be a nontrivial
> project.

Yeah. As I said, we'd be happy to give help/reviews/guidance since we've
done the kernel and userspace part.

> 
> 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.

Yeah, that sounds like a very unlikely combination to be honest.

Christian