Re: Fallout from dlopen() blocking SIGSYS

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

On 4/12/2019 23:08, Rich Felker wrote:
> The right solution probably involves using seccomp with a tracer 
> process, or if the dlopen calls are the only thing you need to 
> filter, interposing dlopen to prevent the nasty library from calling
>  it.

In the case of the EME/DRM modules, the use case is that we don't
(necessarily) trust the (closed source, proprietary) module. It's
shipped as a .so (currently, it really is libwidevinecdm.so), so we want
to be sure that we only call dlopen() on it *when already inside* the
sandbox. This in order to prevent some craftily written header (or
STT_IFUNC shenanigans) from owning us.

I singled this one out because it's the place where we intentionally do
the dlopen() inside.

There's a few other places where we end up using dlopen() inside the
sandbox where we perhaps don't necessarily need to. Most of those are
fixable *in theory*, but more problematic in practice as the libraries
tend to be those shared with other applications...and this is how I
found out that at least on Ubuntu Chromium ends up installing its
private, duplicate copies of those...sigh.

> Or, just patching the nasty library not to do nasty things you don't 
> want it to do.

I doubt this is something we can realistically do here.

-- 
GCP