1901642 - Sandbox: seccomp sandbox violation: pid ..., tid ..., syscall 167

Status: VERIFIED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Matthew Turnbull [Bluefang]]

Attachment: firefox_sandbox_errors.txt

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

Steps to reproduce:

I'm running Firefox in a band new arm64 Gentoo Linux VM (QEMU/UTM on an M2 MacBook Pro)

When attempting to play media (i.e. YouTube, Slack notifications) I get a number of seccomp sandbox violation and NS_ERROR_DOM_MEDIA_DECODE_ERR errors.

https://crash-stats.mozilla.org/report/index/bf45fbf9-5ad9-400b-b988-720fc0240610#tab-details

syscall 167 seems to line up with prctl

https://hg.mozilla.org/mozilla-central/file/c6d003a3edf393c7153c849f17623142693bc9f4/security/sandbox/chromium/sandbox/linux/system_headers/arm64_linux_syscalls.h#l690

Comment 1

[:gerard-majax]

weird, it's already allowed: https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/security/sandbox/linux/SandboxFilter.cpp#2116-2129

Comment 2

[:gerard-majax]

Since you repro easily, can you do a run with MOZ_SANDBOX_LOGGING=1 and collect logs of those violations ? It should help verify the parameters of prctl(). (when bug 1884378 lands it will be doable from the profiler)

Comment 3

[:gerard-majax]

nevermind i missed the attachment

Comment 4

[:gerard-majax]

ok 23 is PR_CAPBSET_READ, it's allowed in the SandboxPolicyCommon but not on Utility process (override) ? https://searchfox.org/mozilla-central/rev/4c8627a76e2e0a9b49c2b673424da478e08715ad/security/sandbox/linux/SandboxFilter.cpp#737-738

Comment 5

[:gerard-majax]

Attachment: Bug 1901642 - Return EINVAL for prctl(PR_CAPBSET_READ) on Utility process r?gcp!

Comment 6

[Matthew Turnbull [Bluefang]]

Attachment: sandbox.log

Here's the more verbose sandbox log in case it's still useful

mkdir /tmp/ff
MOZ_SANDBOX_LOGGING=1 firefox -no-remote -profile /tmp/ff "https://www.youtube.com/watch?v=cOM-2GTj-ao" 2>&1 | tee /tmp/ff/sandbox.log

Comment 7

[:gerard-majax]

looks like libcap does this prctl call from cap_get_bound() but i can't find any calls in glibc, while the stack shows lots of ld-linux-aarch64 before the libcap. i'm not sure where it is coming from

Comment 8

[:gerard-majax]

So I'm going to handle it as we do on Content process (accept but return EINVAL), but i cannot find precisely where the call is coming from, hence I'm unsure how it is going to react. I'm pushing for an aarch64 shippable build on try, can i ask you to give it a test to make sure it is fixing the problem? (I'll share the link once the build is ready)

Comment 9

[:gerard-majax]

So the linux aarch64 shippable should be OK from https://treeherder.mozilla.org/jobs?repo=try&author=alissy%40mozilla.com&selectedTaskRun=TihGbfWGTDGUCHqqrIGs4w.2, especially: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/TihGbfWGTDGUCHqqrIGs4w/runs/2/artifacts/public/build/target.tar.bz2

download and extract, run (against a new profile if you prefer but since you're running nightly it's low risk), and it should work

Comment 10

[:gerard-majax]

I'm going to land it that will be faster

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/985fa3d16308
Return EINVAL for prctl(PR_CAPBSET_READ) on Utility process r=gcp

Comment 12

[Matthew Turnbull [Bluefang]]

Attachment: Sandbox debug from TihGbfWGTDGUCHqqrIGs4w.2

So, good news is I'm not seeing the sandbox violation error anymore, however media playback is still broken.

I included an updated sandbox debug log in case it's still a sandbox issue, or if this should be considered closed and I should open a new bug for the media issue.

Comment 13

[:gerard-majax]

There are errors trying to open libavcodec, but I'll verify more next week. Make sure you have correct ffmpeg installed on the system, also one of the next update should bring it in case the issue is from the try build itself.

Comment 14

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/985fa3d16308

Comment 15

[Matthew Turnbull [Bluefang]]

Just closing the loop on this - the nightly build, with this fix, addressed the sandbox error and media playback is also working.

Mysteriously, I went back and re-tried the trybuild and it now also has functional media playback. While things were broken, I did verify that my arm64 and x86_64 systems had identical ffmpeg installations (same version, install paths, build flags). So some other system update installed in the interim may have contributed, though I'm as a loss as to which.

Regardless, thanks for the quick turn around!

Comment 16

[:gerard-majax]

Thanks for confirming at least!