1309098 - SandboxBroker blocks /dev/snd/controlC0, which prevents using ALSA on Linux

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Spawned from bug 1247056 comment 167.

drJeckyll found out that compiling Firefox on Linux with --enable-alsa and --disable-pulseaudio results in no sound being played anymore in bug 1247056 comment 166.

I see that the content sandbox recent tightening [1] is denying access to some files when cubeb is trying to start:
> Sandbox: SandboxBroker: denied op=0 rflags=2000002 perms=3 path=/dev/snd/controlC0 for pid=37387 error="No such file or directory"
> Sandbox: SandboxBroker: denied op=0 rflags=2000002 perms=3 path=/dev/snd/controlC0 for pid=37387 error="No such file or directory"
> [Child 37387] WARNING: AudioStream::OpenCubeb() 7f8044a08700 failed to init cubeb: file dom/media/AudioStream.cpp, line 377

To confirm this, drJeckyll and I did the following:
- In about:support, in the "Graphics" section, the "Audio Backend" showed "alsa" (this shows that we at least tried to use ALSA.)
- In about:config, "security.sandbox.content.level" is at 2 by default; changed it to 1, restarted Firefox, and sound was working again.


Interestingly, when I tried to enable pulseaudio only (the default now), I also got sandbox issues:
> Sandbox: SandboxBroker: denied op=6 rflags=700 perms=3 path=/run/user/1000/pulse for pid=64481 error="Permission denied"
> Failed to create secure directory (/run/user/1000/pulse): Permission denied
> [Child 64481] WARNING: Could not get a cubeb context.: 'rv == CUBEB_OK', file dom/media/CubebUtils.cpp, line 216
> [Child 64481] WARNING: Can't get cubeb context!: file dom/media/AudioStream.cpp, line 352
But I haven't noticed any new bug about this (which I would have expected if sound stopped working altogether on Linux!), so maybe it's just something wrong on my side for this one.


[1] https://groups.google.com/d/msg/mozilla.dev.platform/V-5G9dWJEXo/S9qxkg9EAgAJ

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Do you know the exact distribution/version/platform?

We have a number of ways of dealing with the ALSA issue, but I want to understand why PulseAudio is failing there (and working elsewhere).

Comment 2

[Mike Hommey [:glandium]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)
> Do you know the exact distribution/version/platform?
> 
> We have a number of ways of dealing with the ALSA issue, but I want to
> understand why PulseAudio is failing there (and working elsewhere).

Second sentence in comment 0: "compiling Firefox on Linux with --enable-alsa and --disable-pulseaudio"

which also means whatever sandbox exception is added can be build-time conditional.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

Yes, but that doesn't answer the question at all. I need to find out why PulseAudio breaks as well. It works on Ubuntu 16.04 on amd64, so what is reporter using?

Comment 4

[Mike Hommey [:glandium]]

You probably already had the pulseaudio daemon running, while gerald probably didn't, triggering code to launch it.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Yes, that's likely, but IIRC we did tweaks to encourage to start it up in the parent.

Comment 6

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

I'm running Ubuntu 16.04 LTS 64-bit in a VM.
I had the pulseaudio service disabled, but if you compile FF with --disable-pulseaudio it shouldn't matter if it's installed.
And I've got the following alsa packages installed:
- alsa-base 1.0.25+dfsg-0ubuntu5 all
- alsa-utils 1.1.0-0ubuntu5 amd64

Let me know if you need more info. (And how to get it, I'm only a Linux amateur!)

Comment 7

[Gian-Carlo Pascutto [:gcp]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #5)
> Yes, that's likely, but IIRC we did tweaks to encourage to start it up in
> the parent.

See this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1259508

Understanding why PA fails to initialize despite this may reveal more about ALSA (rather than simply blowing holes into the sandbox for it).

Comment 8

[drJeckyll]

Can we now return to --enable-alsa issue, because it is what span this bug?

I use Gentoo Linux, and don't have pulseaudio installed.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

Attachment: Bug 1309098 - Add ALSA devices to filesystem policy whitelist.

Review commit: https://reviewboard.mozilla.org/r/84930/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/84930/

Comment 10

[Gian-Carlo Pascutto [:gcp]]

(In reply to drJeckyll from comment #8)
> Can we now return to --enable-alsa issue, because it is what span this bug?

As already explained in the previous comment, the issue affecting PA is potentially the same as the one affecting ALSA, so it's important to understand what is actually going on.

I did a test and on my system ALSA-only mode just works without any workarounds.

I'll check in a VM without a full DE whether I can reproduce the issue.

Comment 11

[drJeckyll]

With patch from comment #9 (https://reviewboard.mozilla.org/r/84930/diff/1#index_header), and with security.sandbox.content.level set to 2 (default) I have sound again.

Comment 12

[Gian-Carlo Pascutto [:gcp]]

Julian, can you see what's up with the PA-hasn't-started-yet use case? If fixing that doesn't fix ALSA as a side effect, I'll just land the patch in here.

Comment 13

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

:gcp I done some testing on a VM in a similar environment as described in Comment 6.

I have disabled pulseaudio by running

> pulseaudio --kill

And setting autospawn=no in $HOME/.config/pulse/client.conf.

Even though we have the early initialization of the cubeb context, but for the pulseaudio it is the case that cubeb_init (and therefore pulse_init) fails when the pulseaudio daemon is not running.

So the singleton instance of the context does not get initialized and the initialization code is triggered again once seccomp is enabled as soon as actual audio replay is requested.

This problem is unrelated to the ALSA problem here, fixing the pulseaudio issue would involve making sure the pulseaudio daemon is started before initializing cubeb.

Comment 14

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 8799813 [details]
Bug 1309098 - Add ALSA devices to filesystem policy whitelist.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/84930/diff/1-2/

Comment 15

[Mike Hommey [:glandium]]

Comment on attachment 8799813 [details]
Bug 1309098 - Add ALSA devices to filesystem policy whitelist.

https://reviewboard.mozilla.org/r/84930/#review97416

::: security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp:148
(Diff revision 2)
> -  // Bug 1312678: radeonsi/Intel with DRI when using WebGL
> +    // Bug 1312678: radeonsi/Intel with DRI when using WebGL
>    policy->AddDir(rdwr, "/dev/dri");
>  
> +#ifdef MOZ_ALSA
> +  // Bug 1309098: ALSA support
> +  policy->AddDir(rdwr, "/dev/snd");

Wasn't the point that pulseaudio also needs alsa, making this not a MOZ_ALSA-only thing?

Comment 16

[Gian-Carlo Pascutto [:gcp]]

(In reply to Mike Hommey [:glandium] from comment #15)
> Wasn't the point that pulseaudio also needs alsa, making this not a
> MOZ_ALSA-only thing?

No. PulseAudio seems to do whatever initialization is needed on these "control" device nodes when it itself starts up, which is before our sandbox activates. ALSA can't do this because it's not persistent in the way PA is.

Comment 17

[Mike Hommey [:glandium]]

Comment on attachment 8799813 [details]
Bug 1309098 - Add ALSA devices to filesystem policy whitelist.

https://reviewboard.mozilla.org/r/84930/#review97480

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5ae2260e20e7
Add ALSA devices to filesystem policy whitelist. r=glandium

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5ae2260e20e7