Closed Bug 1449594 Opened 4 years ago Closed 4 years ago
[snap] Searching for any webpage immediately produces 'Gah
. Your tab just crashed .'
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce: ``` $ snap info firefox tracking: edge installed: 60.0b7-1 (72) 201MB - $ snap version snap 2.32.1 snapd 2.32.1 series 16 ubuntu 17.10 kernel 4.13.0-37-generic $ snap info core tracking: beta installed: 16-2.32.1 (4327) 86MB core ``` Ran the 60.0b7-1 (72) snap in edge by using `snap run firefox` (you can install it by installing snapd and then `snap install firefox --edge`) and typed `google.com` into the address bar. Actual results: Got the 'Gah. Your tab just crashed.' page and the output in Terminal which is attached, or see this link: https://paste.ubuntu.com/p/NtDG5xd2zX/ Expected results: The website should have loaded.
Firefox has the avahi-observe, browser-support, camera, cups-control, desktop, desktop-legacy, gsettings, home, network, opengl, pulseaudio, screen-inhibit-control, unity7, upower-observe, x11 interface connections and I'm using the Ubuntu on Xorg session. This bug is not reproducible in 59.0.2-1 (71) which is in the stable channel.
I think the bug affects 60.0b6-1 (70) (which is in the beta channel) as well (I wish I could edit comments)...though in that typing an address and pressing enter does nothing (also happens in revision 72 I think, but if you play around with it for long enough you may be able to reproduce this particular bug). Also the default home page isn't loading (probably closely related to this bug so I won't file a new one?)
Tracking request: Perma-crash on the newly released snap format. This was confirmed by Canonical. This affects beta but not the current release. Asking for a regression window to know what beta introduced the crash. To do so, run: > snap install firefox > snap refresh --revision XXX firefox Replace XXX by the numbers belows > #70 => 60.0b6-1 > #69 => 60.0b4-1 > #68 => 59.0.1-1 => It looks like 60.0b5 wasn't pushed to the Snap store. > #67 => 60.0b3-1 If you need to verify 60.b5, you can download the snap file here and run: > snap install --dangerous <file>  https://queue.taskcluster.net/v1/task/E2zOZ3o-Rw2FyiIPIE6suw/runs/0/artifacts/public/build/firefox-60.0b5.snap
Errors on Ubuntu 17.10 with Wayland: > Failed to connect to Mir: Failed to connect to server socket: No such file or directory > Unable to init server: Could not connect: Connection refused > (/snap/firefox/x1/firefox:22779): Gtk-WARNING **: cannot open display: :0 > TypeError: browser.contentWindow is null Solved by setting media.cubeb.sandbox = false and restarting. Possibly regressed by Bug 1428952.
Great! I confirm this works on Snap, for me. We can toggle this pref on Snap, momentarily.
Bug 1126437 increased security.sandbox.content.level from 3 to 4 in FF60 and made it fall back to level 3 internally when media.cubeb.sandbox = false. It doesn't crash when the content sandbox is level 3 with cubeb sandbox enabled so it appears the level 4 content sandbox is the real regressor.
What's going on here is more or less what's described in , but I forgot something: that situation can also happen if the browser is run with access to the X server's network namespace but without access to /tmp/.X11-unix. (I mentioned this in one of the commits for bug 1440206, but apparently didn't realize all of the implications.) And that's what's happening here: the application is run in the root network namespace, but it's in a separate mount namespace with a private /tmp. (Wayland doesn't matter for this — Firefox is still using X11 via Xwayland, which for this purpose behaves like regular Xorg. A native Wayland port of Firefox is being worked on, but judging by the bug traffic it's a work in progress.) The ideal solution would be to bind-mount /tmp/.X11-unix into the Snap container. However, I can work around this by not unsharing the network namespace if X11 is in use and that directory doesn't exist; that way we can still block socket APIs with seccomp-bpf.  https://searchfox.org/mozilla-central/rev/b80994a43e5d92c2f79160ece176127eed85dcc9/security/sandbox/linux/launch/SandboxLaunch.cpp#89-95  Which means that the attack described in https://mjg59.dreamwidth.org/42320.html still works, although with Xwayland the scope seems to be limited to other X11 clients.
Non-Snap STR: unshare -Umr # this starts a subshell; use it for the following commands mount -t tmpfs tmpfs /tmp firefox --new-instance
Assignee: nobody → jld
Priority: -- → P1
Attachment 8963927 [details] [diff] already landed, so I'm going to file a separate bug for the sandbox change.
Assignee: jld → jlorenzo
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Can Canonical/Mozilla rebuild the 60.0b8 snap as 60.0b8-2 or should we wait for 60.0b9 (how often are betas released anyway, I can't find docs on that)? :)
60.0b9 was built yesterday. I just made the snap available on the beta channel. For the record, we release betas twice a week, generally on Tuesdays and Thursdays. Ken, do you know whether we can do something about /tmp/.X11-unix in a snap (comment 9)?
Comment on attachment 8963927 [details] [diff] [review] [mozilla-partners/canonical] Set pref "media.cubeb.sandbox" temporarily Approved and merged in github.
Attachment #8963927 - Flags: review?(mozilla) → review+
Yes. It was fixed via a change in the Snap.
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #9) > The ideal solution would be to bind-mount /tmp/.X11-unix into the Snap > container. However, I can work around this by not unsharing the network > namespace if X11 is in use and that directory doesn't exist; that way we can > still block socket APIs with seccomp-bpf. There are no current plans to mount /tmp/.X11-unix into the snap's mount namespace, since X is typically accessed via an abstract socket. That doesn't mean that it cannot be discussed and considered, though. The topic was recently mentioned in a forum thread (https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/4580), so maybe add to that thread to make the case for it?
Comment on attachment 8963927 [details] [diff] [review] [mozilla-partners/canonical] Set pref "media.cubeb.sandbox" temporarily Review of attachment 8963927 [details] [diff] [review]: ----------------------------------------------------------------- For future reference, it would have been better to change security.sandbox.content.level. The media.cubeb.sandbox pref controls audio remoting, and flipping it means you're using a different audio code path which isn't normally used in versions ≥60, isn't being regularly tested, and has already had some bit-rot problems. But there's not much point in changing it now, because with the patch from bug 1450740 it should be possible to just revert this.
You need to log in before you can comment on or make changes to this bug.