1657849 - media plugin seccomp sandbox should allow __NR_sched_setscheduler

Status: UNCONFIRMED

(Core :: Security: Process Sandboxing, defect, P2)

Description

[Szabolcs Nagy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

playing certain audio pod cast (details are not relevant) after a libc update on linux.

Actual results:

no audio plays and firefox hangs.

but it works as expected if i run firefox with MOZ_DISABLE_GMP_SANDBOX=1

Expected results:

(seccomp sandbox failure should never be a hang: it should be clear to the user what security policy violation happened so a reasonable bug report can be sent to distro or other maintainers involved.)

in this case the problem is that the libc update blocks all signals around the sched_setscheduler syscall in pthread_setschedparam to fix a bug: http://git.musl-libc.org/cgit/musl/commit/?id=7cc9496a18c3fa665c286b8be41d790c795e0171

the seccomp 'trap' mechanism is broken in that if sigsys is blocked then the process crashes instead of handling the signal. there are reasons why a libc needs to block all signals around this particular syscall so i think it should be 'allowed' in the media plugin sandbox, i.e. this should be unconditional Allow():

https://searchfox.org/mozilla-central/source/security/sandbox/linux/SandboxFilter.cpp#1470

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Szabolcs Nagy]

sorry the observed hang is probably unrelated to seccomp. (it's just non-deterministic and here it happened with sandbox and not without it, and e.g. hard to reproduce under strace, now i managed to reproduce a hang under strace and there is no seccomp or sigsys involved)

but independently of the hang that i'm dealing with, the mentioned seccomp policy should be fixed: trap policy should not be used for sched_setscheduler.

Comment 3

[Patrycja Rosa [:ptrcnull] (she/her)]

While the details have changed a bit since this bug was opened, it's still very relevant - musl libc may use sched_setscheduler on a new thread right after cloning (link), and blocking the syscall leads in some cases to the thread getting killed by SIGSYS, even though it's supposed to receive an -EPERM; the workaround from bug 1742993 doesn't quite apply either, since it's only for the calling thread.

Comment 4

[Anon]

(In reply to Patrycja Rosa [:ptrcnull] (she/her) from comment #3)

While the details have changed a bit since this bug was opened, it's still very relevant - musl libc may use sched_setscheduler on a new thread right after cloning (link), and blocking the syscall leads in some cases to the thread getting killed by SIGSYS, even though it's supposed to receive an -EPERM; the workaround from bug 1742993 doesn't quite apply either, since it's only for the calling thread.

I am on gentoo and I believe this issue is what is causing tabs to crash https://bugzilla.mozilla.org/show_bug.cgi?id=1883915.

Comment 5

[Anon]

Not sure of a solution to this and looking through the alpine repos im not sure which patch would fix this.

Comment 6

[Patrycja Rosa [:ptrcnull] (she/her)]

We're currently working around it with the following patch: https://git.alpinelinux.org/aports/tree/community/firefox/sandbox-sched_setscheduler.patch

Comment 7

[:gerard-majax]

Maybe you should submit your patch patrycja? with some ifdef specific to musl

Comment 8

[Patrycja Rosa [:ptrcnull] (she/her)]

Attachment: Bug 1657849 - Allow sched_setscheduler(2) on musl libc in GMP and RDD sandbox. r=gerard-majax,jld