Firejail: Firefox needs dbus which conflicts with --net=vnet0

[ghost]

Using firejail in the context of TorMiddlebox, I ran into this issue.

Pointers :
https://github.com/Bylon/TOR_Middlebox/wiki/Firefox---Middlebox-tricks
https://github.com/Bylon/TOR_Middlebox/issues/3

We need here a network sandbox, since the whole point is to redirect the traffic from a firejailed-firefox to Tor. So using --net=none is not an option.

Since we have that network sandbox, the instance of Firefox in the container cannot reach our host's session dbus which is running on a abstract socket.

This would be all good if the intent was to prevent access to our session dbus... but in this case we want such access to be able to read the gconf/unity parameters which are read through dbus calls.

A visible effect of this bug is, for example if you have set menus to display in the title bar (that is a useful option to save precious vertical space), this is not applied to the sandboxed firefox since it is not the default behaviour. Indeed, because the sandboxed firefox cannot access the users configuration, all settings are defaults.

There is apparently a discussion about proxying dbus, which happens if flatpak/bubblewrap, but not here.

Also, so far I have failed to find a workaround to launch another dbus inside the sandbox that would allow getting the gconf/unity parameters.

[smitsohu]

Only commenting on two aspects:

There is apparently a discussion about proxying dbus, which happens if flatpak/bubblewrap, but not here.

It is maybe worth noting that the flatpack proxy might get obsoleted by upstream development. Though this looks still early stage.
https://bugs.freedesktop.org/show_bug.cgi?id=100344
https://bugs.freedesktop.org/show_bug.cgi?id=101902

Also, so far I have failed to find a workaround to launch another dbus inside the sandbox that would allow getting the gconf/unity parameters.

Does something like firejail --net=vnet0 --profile=/etc/firejail/firefox.profile dbus-launch firefox work for you? This way you get a dbus instance inside the sandbox that should be able to read and write dconf. If some settings are stored outside dconf, you will probably need to whitelist the paths.

UPDATE: Looking at the menu issue, I think the reason is that applications need to communicate menu layout and actions via session bus to appmenu. So probably nothing to do with dconf. And, unfortunately, probably not much that can be done about this.

[ghost]

Thanks for your answer.

About your "UPDATE", it is indeed what my investigations made me think. This is why I was talking about the _"host's session dbus"_.

So, no, I have already tried with the "dbus-launch" trick, and it still spits out the same error messages and fails to read the menu and action configuration from the host.

A second visible glitch is about libnotify. I installed the add-on _Public IP Display_, which does a notification to tell the user on which Public IP he is running (obviously useful to check it is not your own public IP when running through Tor). When it sees an IP change, this addon normally sends a notification which is passed via libnotify to the notification system used by Ubuntu. In the case of the sandboxed firefox, since it can't either reach the bus for notifications, you get an ugly defaut notification by the addon!

Thanks for the interesting discussions pointers at bugs.freedesktop about the proxyfication of dbus!

In summary, do we say the inconvenience described here is "un-fixable" for now, and that we wait for freedesktop (upstream) to change that situation?

[smitsohu]

In the case of the sandboxed firefox, since it can't either reach the bus for notifications, you get an ugly defaut notification by the addon!

Have you tried if this one is solved by using dbus-launch? Because notify-osd is a dbus-activatable service, you should get a second instance inside the sandbox. It should work like normal.

[ghost]

My bad, in fact I tested this add-on on my host's firefox, it does NOT anyway use systems notifications, so there is no visual difference whether we can reach notify-osd or not.

Trying firejail using simply notify-send, I could indeed get a system notification this way:

• running firejail alone (--net=vnet0)
• running dbus-launch in background in the firejail shell
• exporting the abstract socket
• running notify-send prepended with DISPLAY=:0

Then, I can confirm there is indeed a way to make notifications work from inside firejail with this additional bus.

So we are back at the only bug about "menus and actions"!

[netblue30]

When you start a new network namespace, all your existing sockets will be left in the regular network ns, none of them will be visible in the new network ns. As a result, there will be no dbus functionality.

When dealing with browsers, with or without tor, I don't think you want dbus there - this is a personal opinion. Dbus is quite insecure. There was an attempt to put dbus functionality in Linxu kernel and secure it, however it failed. The dbus proxies I've seen so far can be bypassed, an intruder can go directly to the abstract socket.

[ghost]

You are very correct!

Even more since I have done that to use the sandboxed-firefox to go through tor: we don't want a shady website accessed through tor messing up with the host!

In fact a workaround to get the "menus and action" back (for instance: private dbus in the firejail) would suit me perfectly, but so far I have failed to get that too.

Note that this is minor compared to the other bug I opened that messes up with vnet0 ... since we speak here of a visual effect that do not prevent us from using firefox, although it can be annoying!

[smitsohu]

The dbus proxies I've seen so far can be bypassed, an intruder can go directly to the abstract socket.

@netblue30 But wouldn't a proxy make sense for apps that need to talk to dbus and run in a new net namespace, so that there actually is no abstract socket anymore?

[SkewedZeppelin]

@Bylon off topic, but you _really really_ should be using Tor Browser instead of Firefox to browse the web over Tor. TBB has an extensive patchset on top of Firefox in order to maximize security and minimize leaks.
See https://wiki.mozilla.org/Security/Tor_Uplift

[ghost]

Sure, and you can do better: run TorBrowser in firejail.

That way you have: firstparty isolation (I use uMatrix for that), fingerprinting protection (blank user agent plus noScript does a decent job at that), tracking protection (uMatrix and private browsing), ... and extra protection on network leaks yet to discover!

[SkewedZeppelin]

@Bylon using a blank useragent makes you easier to fingerprint. The fingerprinting patches of TBB are designed to make every user look alike, and as it gets upstreamed into official Firefox it'll make fingerprinting even harder. But yea +1 on everything else.

Using the relaxed variant of https://github.com/pyllyukko/user.js is also fantastic for regular browsing (along with the rest of course).

[ghost]

uMatrix has a feature to randomly change useragents after a configured time.
I am not using it right now since they have old user agents in it... I'll have to find new "neutral" user agents to put in there so that I don't look too "out of the ordinary-easy to fingerprint"... another thing on my /todo-list!
So beside using an outdated list, the best-for-now was to remove the user-agent, but it is indeed not ideal.

Would you know of such an inconspicuous recent user agent list?

... of course using things like the user agent Safari iPhone sends would be a good idea to blend in, but then a lot of sites will try to throw mobile pages, which is sub-optimal.

[chiraag-nataraj]

Closing since there seems to be a workaround for the main issue and the user no longer exists.