Open Bug 1411629 Opened 7 years ago Updated 2 years ago

Using DBUS_SESSION_BUS_ADDRESS does not work with sandboxing

Categories

(Core :: Security: Process Sandboxing, defect, P2)

57 Branch
Unspecified
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: dkm+moz, Unassigned)

References

Details

(Whiteboard: sb+)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171002220106

Steps to reproduce:

Config: centos7 on x86_64.

Downloaded and extracted firefox 57.0b11.
Started firefox on a new profile.

I have a dbus forwarding using the DBUS_SESSION_BUS_ADDRESS env var. It contains:

 tcp:host=myhostname,port=1234,guid=123b87e06560dddb7a06b6ec59c8c2fc;
unix:abstract=/tmp/dbus-oVzUZRTWVs,guid=1236cb92d63e309a5a800cde59c8c2fc



Actual results:

Firefox starts correctly, but the web page does not display anything: content stays grey. I can open new tabs, interface is still active, but nothing loads.

Terminal shows:

(firefox:26746): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed
Sandbox: seccomp sandbox violation: pid 26841, tid 26876, syscall 49, args 36 139720896990288 12 139720896990192 0 1.

(/foo/soft/firefox-57.0b11/firefox:26841): GLib-GIO-WARNING **: Problems looking up entry in keyring: Error creating directory '/home/myuser/.dbus-keyrings': Permission denied

> ls -ld /home/myuser/.dbus-keyrings
drwx------ 2 myuser software 4096 Oct 25 17:15 /home/myuser/.dbus-keyrings




Expected results:

Firefox should display something :)

If I disable sandboxing using ' export MOZ_DISABLE_CONTENT_SANDBOX=1', firefox works.
If I unset DBUS_SESSION_BUS_ADDRESS, firefox works.
Component: Untriaged → Widget: Gtk
OS: Unspecified → Linux
Product: Firefox → Core
Component: Widget: Gtk → Security: Process Sandboxing
Whiteboard: sb?
Can you reproduce this with MOZ_SANDBOX_CRASH_ON_ERROR=1 set in the environment and submit a crash report?

I didn't think there were any cases left where we'd use dbus while sandboxed other than possibly WebRTC (bug 1394163), and that shouldn't break the entire browser like this (or affect sites that don't use WebRTC).  A crash report should at least show what libraries are involved in calling dbus.
Flags: needinfo?(dkm+moz)
I'm not sure that the report has been correctly sent, as I only have a 'close tab' and 'restore this tab' to click after having filled the form...

Here's the console output:

Sandbox: seccomp sandbox violation: pid 28362, tid 28399, syscall 49, args 36 140332196863056 12 140332196862960 0 256.  Killing process.

###!!! [Parent][MessageChannel] Error: (msgtype=0x150083,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

[Parent 28268, Gecko_IOThread] WARNING: waitpid failed pid:28362 errno:10: file /builds/worker/workspace/build/src/ipc/chromium/src/base/process_util_posix.cc, line 276



Let me know if I can to anything else to help...
Flags: needinfo?(dkm+moz)
Flags: needinfo?(jld)
(Sorry for the delay; I've been dealing with a few other things.)

Two more things to try:
1. Are there any unsent crash reports in about:crashes?
2. Try running with MOZ_CRASHREPORTER_DISABLE=1 and MOZ_SANDBOX_CRASH_ON_ERROR=1 set in the environment; that should cause a stack trace to be written to stderr[*].

[*] https://searchfox.org/mozilla-central/rev/c99d035f00dd894feff38e4ad28a73fb679c63a6/security/sandbox/linux/glue/SandboxCrash.cpp#114-118
Flags: needinfo?(jld) → needinfo?(dkm+moz)
Sure, the about:crash is full ! :)
IIUC, visiting one of the unsubmited crash report submits it ?

Here's a freshly submitted report:

https://crash-stats.mozilla.com/report/index/2d57eb3b-10f4-446e-add9-b645f0171109

Let me know if you still need me to try and get a stack trace.
Flags: needinfo?(dkm+moz)
Flags: needinfo?(jld)
I spent some time looking at bp-2d57eb3b-10f4-446e-add9-b645f0171109 before it was deleted (I assume due to bug 1427111); the reason wasn't SIGSYS, so it wasn't the direct result of “Sandbox: … Killing process.”, but it was interesting: there were references to dbus, and farther up the stack something in nsLookAndFeel that seemed to be asking GTK about style information.  I found debug packages for similar versions of libgtk and libgio, and if those were close enough then it was doing something with a GtkCssProvider which would match the stack frames from Gecko.

However, this was all using Breakpad's “stack scanning” mode, which just searches stack memory for plausible return addresses (used when the crash processing server encounters libraries it doesn't have unwind info for), so the results could be false positives that aren't part of the current call stack.  So there's a lot of fuzziness here, but if it's true it would explain why everything is broken.
Flags: needinfo?(jld)
karlt, does it make any sense that GTK would be using DBus as part of obtaining widget style information?

There may be some non-default configuration involved, in addition to the remote DBus: the browser I'm typing this in has work-in-progress patches for bug 1126437, which would break local DBus as well as remote, and it still works.
Flags: needinfo?(karlt)
I don't have any dbus interaction from the content process on my system.
It is conceivable that a GTK module (add-on) may be opening a bus at
start-up for example, or that a different GTK version does something
different at start-up.

I guess DBUS_SESSION_BUS_ADDRESS could be unset for child processes,
given it is not going to work, but it would be nice to know what is
trying to use that, and understand why recovering from failure to read
is not proceeding as expected.
Flags: needinfo?(karlt)
Marc, are you able to run dbus-monitor, please, and compare output during
Firefox startup with and without MOZ_DISABLE_CONTENT_SANDBOX=1, please?

(In reply to Marc from comment #0)
> (firefox:26746): GLib-GObject-CRITICAL **: g_object_unref: assertion
> 'object->ref_count > 0' failed

Is this message output only when sandbox is enabled?
Priority: -- → P2
Whiteboard: sb? → sb+
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.