[GH-ISSUE #3349] Wiki: Restrict D-Bus

gitea-mirror commented

2026-05-05 08:46:53 -06:00

Owner

Originally created by @rusty-snake on GitHub (Apr 12, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3349

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

Originally created by @rusty-snake on GitHub (Apr 12, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3349 https://github.com/netblue30/firejail/wiki/Restrict-D-Bus

gitea-mirror

2026-05-05 08:46:53 -06:00

closed this issue
added the
wiki
label

gitea-mirror commented

2026-05-05 08:46:56 -06:00

Author

Owner

@matu3ba commented on GitHub (Apr 12, 2020):

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.

@matu3ba commented on GitHub (Apr 12, 2020): Looks very nice. :) Mentioning how to retrieve [lists of dbus services](https://unix.stackexchange.com/questions/46301/a-list-of-available-d-bus-services/46309#46309) on the local system. A short intro what is blocked per default (everything aside what is allowed?) would be great.

gitea-mirror commented

2026-05-05 08:46:57 -06:00

Author

Owner

@kris7t commented on GitHub (Apr 13, 2020):

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.

@kris7t commented on GitHub (Apr 13, 2020): 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](https://github.com/flatpak/xdg-dbus-proxy/blob/15d2803039b1964dc95112d6d1624a291d338c4e/xdg-dbus-proxy.xml#L203), `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](https://blogs.gnome.org/mclasen/2019/07/12/settings-in-a-sandbox-world/), 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](https://docs.flatpak.org/en/latest/sandbox-permissions.html#dconf-access) for some system level settings (I guess window button order and such), but that would be restricted to applications explicitly supporting sandboxing.

gitea-mirror commented

2026-05-05 08:46:58 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 13, 2020):

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?

@rusty-snake commented on GitHub (Apr 13, 2020): > 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`?

gitea-mirror commented

2026-05-05 08:47:00 -06:00

Author

Owner

@kris7t commented on GitHub (Apr 13, 2020):

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.

@kris7t commented on GitHub (Apr 13, 2020): 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.

gitea-mirror commented

2026-05-05 08:47:01 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 19, 2020):

@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 commented on GitHub (Apr 19, 2020): @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 ```

gitea-mirror commented

2026-05-05 08:47:01 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 4, 2021):

https://github.com/netblue30/firejail/discussions/4447

@rusty-snake commented on GitHub (Aug 4, 2021): https://github.com/netblue30/firejail/discussions/4447

gitea-mirror referenced this issue

2026-05-05 09:05:15 -06:00

[GH-ISSUE #3831] Question to bug #2101 #2410

gitea-mirror referenced this issue

2026-05-05 09:05:18 -06:00