Wiki: Restrict D-Bus

[rusty-snake]

https://github.com/netblue30/firejail/wiki/Restrict-D-Bus

[matu3ba]

Looks very nice. :)
Mentioning how to retrieve lists of dbus services on the local system.
A short intro what is blocked per default (everything aside what is allowed?) would be great.

[kris7t]

Regarding org.freedesktop.Notifications: I think the main problem is that Gnome Shell implements the notification service over the same D-Bus connection as the rest of its interfaces. Therefore all Gnome Shell D-Bus objects are exposed via the org.freedesktop.Notifications name. According to its man page, xdg-dbus-proxy can filter D-Bus messages per interface. I think something like --see=org.freedesktop.Notifications --call=org.freedesktop.Notifications.*@/org/freedesktop/Notifications --broadcast=org.freedesktop.Notifications.*@/org/freedesktop/Notifications would be sufficient. Making firejail pass such options to xdg-dbus-proxy is trivial to implement, although may significantly increase profile complexity (again).

Of course, this vulnerability is not exclusive to Notifications. It seems filtering by name is not sufficient for services which expose objects with different level of sensitivity over multiple bus names. This may be something to consider when extracting D-Bus filter rules from flatpak manifests. In theory, any --talk rule can be vulnerable, except maybe org.freedesktop.portal.*, which were explicitly designed for sandboxing (and even those probably need additional configuration).

Regarding ca.desrt.dconf, according to this post on the Gnome blog, blocking in should be fine for most applications -- GSetting has a keyfile backend. However, at least on my Arch system, there is no ~/.var directory, which would supposedly store the keyfiles. We might need to whitelist it in the filesystem. There is also a portal for dconf access for some system level settings (I guess window button order and such), but that would be restricted to applications explicitly supporting sandboxing.

[rusty-snake]

Making firejail pass such options to xdg-dbus-proxy is trivial to implement, although may significantly increase profile complexity (again).

The most names/interfaces have the same name only . replaces with /. What about dbus-user.talk org.freedesktop.Notifications implies interface /org/freedesktop/Notifications, org.gnome.Shell.Screenshots implies /org//gnome/Shell/Screenshots?

[kris7t]

I don't think there is a one-to-one(-to-one) mapping between names, interfaces and object paths. For example, org.kde.StatusNotifierWatcher exposes the object /StatusNotifierWatcher with the interface org.kde.StatusNotifierWatcher, i.e., the /org/kde prefix is missing from the object path. It can be even more chaotic: both org.mpris.MediaPlayer.firefox.instance41 and org.mpris.MediaPlayer2.spotify expose /org/mpris/MediaPlayer2 with the interfaces org.mpris.MediaPlayer2 and org.mpris.MediaPlayer2.Player.

It is just a mess: bus names correspond to applications, not services, and an application can expose both privileged and non-privileged services (which is probably in itself a bad idea, but that's what we got). The closest we get to specifying a particular service is the interface, but you still get cookie-cutters like org.freedesktop.DBus.Properties, which allows reading and writing all properties regardless of the interface that defines them.

Object paths a weird, too. You would think /org/freedesktop/portal/desktop (exposed by org.freedesktop.portal.Desktop) implements org.feedesktop.portal.Desktop, but there is no such interface. Instead, it implements a bunch of interfaces like org.freedesktop.portal.Screenshot and org.freedesktop.portal.FileChooser.

The case you mention might be reasonably common, although looking through the session bus with QDBusViewer, more applications don't follow it than those which do. So I am unsure whether even something like dbus-user.talk-strict bus-name as an alias of --talk=bus-name --call=bus-name.*@bus-name-with-.-replaced-by-/* --broadcast=bus-name.*@bus-name-with-.-replaced-by-/* would be useful, and having that as a default behavior for dbus-user.talk is probably useless.

[rusty-snake]

@kris7t what about an own option for specifying allowed interfaces on a name, that is ignored if there is no dbus-user.talk NAME and otherwise applied. It would us allow to create a common.inc file for this.

dbus-user filter
dbus-user.own org.mpris.MediaPlayer.firefox.*
dbus-user.talk org.freedesktop.Notifications
dbus-system none

include D-Bus-interfaces-common.inc

[rusty-snake]

#4447