1104619 - (sb-audio) [meta] Sandboxing improvements when audio playback & recording are remoted

Status: NEW

(Core :: Security: Process Sandboxing, enhancement, P3)

Comment 1

[Gian-Carlo Pascutto [:gcp]]

WIP is being done on this branch: 
https://github.com/gcp/gecko-dev/tree/sandbox-av
https://github.com/gcp/gecko-dev/compare/sandbox-av

Comment 2

[Julian Hector [:tedd] [:jhector]]

Should this be tracked by sandboxing? It looks like this could fix Bug 1259283.

Comment 3

[Julian Hector [:tedd] [:jhector]]

Moving to sblc2 because this is currently not blocking enabling seccomp on nightly. However, it will allow us to revert the patch landed as part of Bug 1259508, once audio is remoted.

Comment 4

[Julian Hector [:tedd] [:jhector]]

Discussed this with :gcp over irc, he is not currently working on it.

Comment 5

[Paul Adenot (:padenot)]

We should have a look at how chromium does this before proceeding. Also don't hesitate to ask any question, this is full of gotchas.

This is the code on the host side (= Chrome process for us): https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_renderer_host.cc?sq=package:chromium&rcl=1474529952&l=349

Comment 6

[Julian Hector [:tedd] [:jhector]]

Thank you very much.

So far my approach is to remote the cubeb API found in cubeb.h. But I am currently dealing with a threading issue since I created a sync protocol. It seems that the Send method is called from a thread it can't block on.

I probably have to do something similar to the LockAndDispatch [1] that :gcp did on PCameras, which makes this slightly more complicated.

[1] http://searchfox.org/mozilla-central/rev/8910ca900f826a9b714607fd23bfa1b37a191eca/dom/media/systemservices/CamerasChild.cpp#188

Comment 7

[Julian Hector [:tedd] [:jhector]]

Oh and this is my working branch:

https://github.com/jhector/gecko-dev/tree/bug-1104619-remote-audio

Comment 8

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Retitling this bug to match what its new purpose seems to be.  The audio remoting discussed in previous comments seems to now be covered in bug 1362220.

Comment 9

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Audio access is remoted on Linux and has been for years now. The media.cubeb.sandbox pref still exists, and I think the media people might want to keep it around for troubleshooting or debugging, but we don't need to support flipping that pref without also explicitly turning off content sandboxing. I'm told that that's already the case on Windows. It also parallels what we did with WebGL remoting — if it's turned off then it's also necessary to explicitly turn off security.sandbox.content.headless (which is dangerous, especially on X11).

This has already sort of started happening to some extent; see bug 1604269 which didn't gate the change on sandbox level, and in general we don't test the semi-sandboxed configuration that currently results from flipping media.cubeb.sandbox (it's insecure and unsupported), so there could be other cases of accidental breakage as well.

There are three places the sandbox is weakened in response to that pref, which we could remove:

• Clamping the effective sandbox level to 3
• Sharing the SysV IPC namespace (if the ALSA backend is compiled in)
• Preloading the audio backend, meaning that the process holds a connection to the audio server which could be a sandbox escape vector

The last one is more complicated, because — tested on Debian using Pipewire — audio is broken without that workaround (the first objectionable syscall is umask) even if the sandbox isn't otherwise changed from the status quo. Removing that would mean that sandboxing would have to be turned off completely for non-remote audio, rather than just using an untested weak policy (level 3). Which brings me to the next set of things that we probably want to rip out:

• Basically everything in SandboxFilter.cpp that's ifdef'ed on MOZ_PULSEAUDIO or MOZ_ALSA.
• And anything with comments mentioning non-remote audio, if not already covered by the above.

When we do that, we'll want to make sure that crash reports record whether media.cubeb.sandbox was flipped, in case there's anyone using Nightly with weird pref settings.