Fallout from dlopen() blocking SIGSYS

[Gian-Carlo Pascutto <gpascutto at mozilla dot com>]

(reposting here per request from Florian Weimer)

This glibc patch:

Block signals during the initial part of dlopen
(a2e8aa0d9ea648068d8be52dd7b15f1b6a008e23)

is going to break every Firefox release of the last few years. We use a
seccomp-bpf filter to sandbox various processes. In some of these
processes we don't want to do a dlopen() of untrusted code while we're
not sandboxed yet, for example in the process we use to isolate Google's
Widevine DRM modules from any private data on the system.

seccomp-bpf will intercept various filesystem related syscalls and raise
SIGSYS, at which moment our code will contact a broker in the parent
process that checks if the file that's being want to read is acceptable
to us, and then passes down the file handle.

This obviously only works if the code that we load doesn't block the
SIGSYS signal, so we interpose the signal handling functions to stop
that from happening:
https://searchfox.org/mozilla-central/rev/04d8e7629354bab9e6a285183e763410860c5006/security/sandbox/linux/SandboxHooks.cpp#42

But, ld.so being the linker itself, this technique doesn't work for it.
This means that it will succeed in blocking SIGSYS, try open() (or
similar), and fail because seccomp-bpf will block it but nobody will
handle the raised signal. Now, we hit a Linux seccomp-bpf design issue:
SECCOMP_RET_TRAP will, if the signal is either ignored or blocked,
unblock it and reset it to SIG_DFL (effectively).
At this point, Firefox crashes.

We are tracking the problem here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1600574

This is a particularly nasty problem for us - the only
solution/workaround so far is to disable sandboxing, and if affects old
releases such as ESR.

I'm not clear if it affects other seccomp-bpf users like Chromium - they
use almost exactly the same way of dealing with filesystem access, but
(all AFAIK) only for the sandboxed GPU Process which might not need to
dlopen() things (and I'm not sure that particular sandbox is enabled on
regular Linux to begin with).

We might need to intercept the system calls that set up the signal
handling and basically undo the above glibc change, while trying to
ensure the conditions that caused you to make the above change don't
hold. Or something. We're still thinking about how to cope with this.

-- 
GCP