1770388 - Enable Utility Audio Decoder on Nightly for OpenBSD

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, enhancement)

Description

[:gerard-majax]

Bits are there, we will toggle the switch once we have proper sandboxing rules verified and landed on OpenBSD's side.

Comment 1

[:gerard-majax]

Attachment: Bug 1770388 - Enable Utility AudioDecoder for OpenBSD r?gaston!

Comment 2

[:gerard-majax]

Attachment: unveil.utility-audioDecoder

Comment 3

[:gerard-majax]

Attachment: pledge.utility-audioDecoder

Comment 4

[:gerard-majax]

Attachment: unveil.utility-audioDecoder

Comment 5

[:gerard-majax]

Attachment: unveil.utility

Comment 6

[:gerard-majax]

Attachment: pledge.utility

Comment 7

[:gerard-majax]

• Utility generic sandbox passes the ipc/glue/test/browser/browser_utility_start_clean_shutdown.js
• Utility AudioDecoder passes the ipc/glue/test/browser/browser_utility_multipleAudio.js

Other tests have mechanism that seems not ready for OpenBSD, so I can't really easily verify if crash reporter, profiler, memory reporting for example are not missing some sandboxing rules. But this should be a good default.

Comment 8

[Sebastien Marie [:semarie]]

for utility-audioDecoder process: pledge(2) promises "rpath wpath cpath" and unveil(2) "/tmp rwc" might be replaced by pledge(2) "tmppath".

"tmppath" is a special promise which permits a process to play with temporary files (the permitted syscalls are reduced comparing to {r,w,c}path). the unveil part is automatically managed by the kernel (no need to mention it in unveil.utility-audioDecoder

Comment 9

[Sebastien Marie [:semarie]]

the promise "ps" in pledge.utility-audioDecoder is a bit weird. if it is due to mozilla code, some code reordering might be useful (get some processes' properties before entering in the sandbox, but not necessary as part of this commit) ; but if it is due to dlopened code, it might be more complex to do.

I would be interested to know the dmesg output when the violation is reported.

Comment 10

[Landry Breuil (:gaston)]

i'm also surprised to have so many pledges in pledge.utility-audioDecoder (especially ps & prot_exec) while pledge.rdd only has:

stdio
rpath # gtk tries to access /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
tmppath
recvfd
sendfd
unix # getsockopt

and from my understanding, before audio decoding is offloaded to this process it was done by the rdd process. I'll see what happens at runtime after actually testing.

i also agree with :semarie on the replacement of rpath/wpath/cpath by tmppath as it is for the rdd process :)

Comment 11

[Landry Breuil (:gaston)]

for the ones following along: the current pledge/unveil configs for each process types are in http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/mozilla-firefox/files/

Comment 12

[Sebastien Marie [:semarie]]

:gaston, if I remember correctly, "prot_exec" is required to dynamically load libraries via dlopen(3). so it might be expected here.

Comment 13

[:gerard-majax]

I just shared what I got from running tests locally, but I'll let you take care of finalizing those rules ? Once it's in OpenBSD's sources, I can land my changes.

Please dont forget to needinfo me once the rules are ready on your side so I can push my change, except if you are okay I land them right away?

Comment 14

[Landry Breuil (:gaston)]

i'd rather have something tested at runtime before enabling it by default, but so far i havent been able to get a working nightly setup (cf bug #1770548) but on the other hand i'd like to have it enabled upstream for 102 :)

Comment 15

[:gerard-majax]

(In reply to Landry Breuil (:gaston) from comment #14)

i'd rather have something tested at runtime before enabling it by default, but so far i havent been able to get a working nightly setup (cf bug #1770548) but on the other hand i'd like to have it enabled upstream for 102 :)

That's fine by me, your schedule on enabling is mine. Regarding bug 1770548 unfortunately that'd require me to have X11 installed and while I can verify bits with mach test debugging everything on OpenBSD is more than I can commit at the moment :)

Comment 16

[:gerard-majax]

So, I could get my debug build working as mentionned in bug 1770548. Under GNOME (might have a play here?), I could browse to YouTube and while my VM's sound is not wired to outside:

• a utility process was started
• when idling on the paused video, it would yield < 0.5% of CPU time according to ps
• when video playback was resumed, CPU would rise between 1.5% and 2.5%, again according to ps

If you feel my rules can be improved, feel free to do so when committing to OpenBSD's git :)

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/42b4c3a50309
Enable Utility AudioDecoder for OpenBSD r=gaston

Comment 18

[:gerard-majax]

Landing as suggested by :gaston on IRC.

Comment 19

[Landry Breuil (:gaston)]

now that i've fixed my blunder in bug #1770548 i've been able to properly test it, and i can confirm i have sound and an utility process is spawned. Will ktrace the utility process and figure out if the unveil/pledge configs have to be amended. I suppose testing various audio formats should exercise different codepaths in decoding libraries ?

Comment 20

[Landry Breuil (:gaston)]

i've been able to have working audio on https://heyjuniore.bandcamp.com/album/un-deux-trois with stdio rpath tmppath recvfd sendfd unix for pledge, rpath is only needed because gtk tries to access /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache. Do you remember with which format you had to add ps & prot_exec ?

testing with a random video from https://invidious.snopyta.org/, video doesnt start but i have some sysctl KERN_PROC_ARGS calls (which were neuteured in my build iirc) in the utility process failing because of pledge, and this on stderr:

[Child 26346, MediaDecoderStateMachine #1] WARNING: Decoder=b33b19dd800 state=DECODING_METADATA Decode metadata failed, shutting down decoder: file /home/landry/src/m-c/dom/media/MediaDecoderStateMachine.cpp:370
[Child 26346, MediaDecoderStateMachine #1] WARNING: Decoder=b33b19dd800 Decode error: NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006) - static MP4Metadata::ResultAndByteBuffer mozilla::MP4Metadata::Metadata(mozilla::ByteStream *): Cannot parse metadata: file /home/landry/src/m-c/dom/media/MediaDecoderStateMachineBase.cpp:151

those failures/errors dont go away if i readd prot_exec & ps pledges to the utility-audioDecoder process.

Comment 21

[:gerard-majax]

No sorry but if you run tests ipc/glue/test/browser/browser_utility_multipleAudio. Js you can find pretty easily. Will run both on opt and debug build

Comment 22

[Landry Breuil (:gaston)]

correction... it works (eg i have sound etc) on https://invidious.snopyta.org/watch?v=6q8iy7yq6_E but not on https://invidious.snopyta.org/watch?v=e7yRd_Tk9XY - so format decoding issues ?

Comment 23

[:gerard-majax]

No idea and i wont be near my laptop and desktop before a few hours. Try running with MediaFormatReader:5 ? AAC depends on ffmpeg also

Comment 24

[Landry Breuil (:gaston)]

i think i figured out that the failures were due to rdd process crashing because of the forbidden KERN_PROC_ARGV sysctl, will retest with a build with that locally fixed. And various formats.

Comment 25

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/42b4c3a50309

Comment 26

[Landry Breuil (:gaston)]

after fixing the rdd process failure/crash that was a local problem, been able to use sound with various invidious urls. will need to make sure all formats are covered, i've seen some prot_exec violations in dmesg though, due to (i guess) some underlying decoding lib doing funky things with mmap:

 82841 firefox  RET   mmap 6930070437888/0x64d88630000
 82841 firefox  CALL  mmap(0x64d88964000,0xa8e000,0x5<PROT_READ|PROT_EXEC>,0x12<MAP_PRIVATE|MAP_FIXED>,14,0x333000)
 82841 firefox  PLDG  mmap, "prot_exec", errno 1 Operation not permitted
 82841 firefox  NAMI  "firefox.core"

pledge kills the audio decoder process if there's no prot_exec. So far, main/content/gpu processes also have this pledge allowed, so i guess we'll have to live with it for now.

Comment 27

[Landry Breuil (:gaston)]

Fwiw the 'ps' pledge is needed (when using a selfbuilt binary from hg) mostly because of https://searchfox.org/mozilla-central/source/xpcom/build/BinaryPath.h#201 but that one is neuteured in the OpenBSD port via http://cvsweb.openbsd.org/ports/www/mozilla-firefox/patches/patch-xpcom_build_BinaryPath_h?rev=1.2&content-type=text/x-cvsweb-markup which avoids calling the sysctl().

Comment 28

[Landry Breuil (:gaston)]

i've added the pledge/unveil configs to the wip repo for the port in https://cgit.rhaalovely.net/mozilla-firefox/commit/?id=6dc14bba32a16de69b87af326578862180d7f958 - thanks alex !