glibc 2.32 rseq support incompatible with Firefox sandbox

[Gian-Carlo Pascutto]

On Thu, Jul 9, 2020, 18:34 Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:

>
> this sandbox design is broken: blocking signals is
> valid


That the design is broken is somewhere between an irrelevant and pointless
observation: it was introduced back in 2012 by Chromium. I'm going to guess
they did it this way because Seccomp-Trap was the only available option to
get a usable browser sandbox until very recent 5.x kernels (which means it
will potentially stay the only way for modern glibc on older kernels?).
Firefox hits it as well because we share large parts of the sandbox
implementation with Chromium.

We discussed the signal blocking issue in a previous thread - glibc wanting
to be more strict with signal blocking during thread setup - and have been
discussing with Chromium people on moving towards the more modern NOTIFY. I
believe they have a prototype implementation in review. We have some dreams
of getting to work on one before the end of the year. In any case we'll be
stuck with this for a while more.

and new syscalls are added all the time (e.g.
> all time related syscalls just got replaced on 32bit
> systems).
>

We try to proactively patch these in when we become aware of the need. It's
also possible to add them via prefs so you don't need a browser rebuild,
see: https://wiki.mozilla.org/Security/Sandbox#Customization_Settings

If all we need to do here is allow rseq, then it's not really a problem. If
it's a more fundamental issue with the signal blocking, we'll need to
figure out a workaround until sandboxed browsers can add support for and
add the entirely new seccomp implementation.

-- 
GCP

>