dropbox: How to restrict dbus with fine-grained permissions?

[amidukr]

Hi,

I was reviewing Dropbox profile bundled together with firejail recently, and it doesn't has granular permissions for DBus, it seems that by default dbus is open for all. Actually impact is well described here:
https://github.com/netblue30/firejail/wiki/Restrict-DBus

I've tried to update a little bit the profile, and I've found out a way how to log dbus communication, however I've confused about certain aspect.

According to DBus communication log, I see that this messages are filtered, and it really numerous of them.

dropbox.dbus.log|6 col 1-23| Filtering message due to arg0 org.a11y.Bus, policy: 0 (required 1)
dropbox.dbus.log|10 col 1-23| Filtering message due to arg0 org.freedesktop.Notifications, policy: 0 (required 1)
dropbox.dbus.log|20 col 1-23| Filtering message due to arg0 org.kde.StatusNotifierWatcher, policy: 0 (required 1)
dropbox.dbus.log|61 col 1-23| Filtering message due to arg0 org.gtk.vfs.Daemon, policy: 0 (required 2)
dropbox.dbus.log|67 col 1-23| Filtering message due to arg0 org.gtk.vfs.Daemon, policy: 0 (required 1)
dropbox.dbus.log|90 col 1-23| Filtering message due to arg0 org.gtk.Settings, policy: 0 (required 1)
dropbox.dbus.log|94 col 1-23| Filtering message due to arg0 org.gtk.Settings, policy: 0 (required 2)
dropbox.dbus.log|98 col 1-23| Filtering message due to arg0 org.kde.StatusNotifierWatcher, policy: 0 (required 1)
dropbox.dbus.log|114 col 1-23| Filtering message due to arg0 org.gtk.Settings, policy: 0 (required 1)
dropbox.dbus.log|123 col 1-23| Filtering message due to arg0 org.gnome.Shell.Extensions, policy: 0 (required 1)
dropbox.dbus.log|127 col 1-23| Filtering message due to arg0 org.gnome.Shell.Extensions, policy: 0 (required 2)
dropbox.dbus.log|137 col 1-23| Filtering message due to arg0 org.gnome.Shell.Extensions, policy: 0 (required 1)
dropbox.dbus.log|165 col 1-23| Filtering message due to arg0 org.gnome.Shell.Extensions, policy: 0 (required 1)
dropbox.dbus.log|169 col 1-23| Filtering message due to arg0 org.gnome.Shell.Extensions, policy: 0 (required 2)
dropbox.dbus.log|179 col 1-23| Filtering message due to arg0 org.gnome.Shell.Extensions, policy: 0 (required 1)

However when I've checked flatpak, how they doing it permissions through flatseal, I can see only two dbus names enabled for dropbox, while firejail dbus log has much more messages filtered.

1. Also I am not really understanding this flatpak wildcard. Is it really secure to declare ownership for such global namespace in dbus?
2. How could I know from dbus log, which dbus names should I open for ownership?
3. Do I need to open all this message from above for dbus talks, or I just need to open only two messages like flatpak doing?
   3.1 Still curious about principle, why flatpak skipping so many dbus names for dropbox?

BTW: I can test it on my local and make Pull Request for dropbox profile if needed, to have fine-grained permissions for dropbox.

UPD: dbus log file: dropbox.dbus.log

[rusty-snake]

Also I am not really understanding this flatpak wildcard. Is it really secure to declare ownership for such global namespace in dbus?

Of course not. However it is necessary dur to bad¹ API design.

This permission is for tray icons.

Also not that it is very contra intuitive what you actually can do when you're allowed to talk to a name. The org.freedesktop.Notifications for example can be used to execute coommands (e.g. /bin/bash -c "…") on the host.

¹ bad in terms of sandboxing friendly

How could I know from dbus log, which dbus names should I open for ownership?

It's hard to tell. Generally the most names are talk. Names containing the program name are usually own.

You can also compare the list of dbus names on your bus before starting the first program and while it is running unsandboxed. However this does not work if the program has dbus activatable names.

Do I need to open all this message from above for dbus talks, or I just need to open only two messages like flatpak doing?

It depends. Do you want to make everything work (does Dropbox has plugins, user script, ...?). Or only the main functionality.

Programs often try to talk to something w/o actually needing it.

3.1 Still curious about principle, why flatpak skipping so many dbus names for dropbox?

Flatpak is using portals which are always allowed. Also nobody said the the flatpak Dropbox is complete.

[amidukr]

Also not that it is very contra intuitive what you actually can do when you're allowed to talk to a name. The org.freedesktop.Notifications for example can be used to execute coommands (e.g. /bin/bash -c "…") on the host

Regarding org.freedesktop.Notifications, on this page

https://github.com/netblue30/firejail/wiki/Restrict-DBus

it said that, it being an issue prior to GNOME prior to 3.36.1, is it still remains an issue on recent versions of Gnome with /bin/bash -c like you said?

It depends. Do you want to make everything work (does Dropbox has plugins, user script, ...?). Or only the main functionality.

Programs often try to talk to something w/o actually needing it.

Honestly speaking I didn't tried to run flatpak, maybe it just simply doesn't work with this only two, while I am breaking my head why it is so. I just tried to copy setting from flatpak, dropbox started but dropbox button in tray simply not responsive.

I've tried to run by giving permission to all filtered from list above, and tray works. I am not really understand roles for all this messages, I can just assume they all needed for some reason for dropbox tray to work.

• I've tried to play, more and to make tray responsive, I only needed this dbus to enable dbus-user.talk org.gnome.Shell.Extensions.
• Actaully any help button doesn't work without it failingorg.gtk.vfs.Daemon, seems it trying to open browser, I can assume it is not really good for sandboxing, but it offers a user feature.
• org.a11y.Bus - it is an accessibility thing, I don't need it but anyone who, use any screenreader, I guess dropbox needs to communicate there.
• Also I see that dropbox failing with gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed because of missing org.gtk.Settings.

Perhaps there some issues with DBus API design, for example this thing org.gtk.Settings can give too many permissions, but whatever dropbox requested it looks legit to me, if I block any of that dbus, dropbox will lose some functionality.

The problem is, even I've gave all this names to dbus, dropbox tray not working well, tray has some menus available, but it says it connecting. When I am disabling dbus filtering, dropbox works well under firejail, and I don't seen any other filtered messages on dbus.log.

Maybe this is causing an issue?

C10: -> org.freedesktop.DBus fake GetNameOwner for org.gnome.Shell.Extensions
...
B11: <- org.freedesktop.DBus return error org.freedesktop.DBus.Error.NameHasNoOwner from C10

Of course not. However it is necessary dur to bad¹ API design.

This permission is for tray icons.

I am still concerned about that wildcard, is any way I can know if I can reduce list of ownership.

[rusty-snake]

Regarding org.freedesktop.Notifications, on this page

https://github.com/netblue30/firejail/wiki/Restrict-DBus

it said that, it being an issue prior to GNOME prior to 3.36.1, is it still remains an issue on recent versions of Gnome with /bin/bash -c like you said?

No, with GNOME >= 3.36.1 org.freedesktop.Notifications is pretty much safe. However there are more implementations for org.freedesktop.Notifications (KDE, Xfce, sway, ...). And other names than org.freedesktop.Notifications are still unsafe.

org.a11y.Bus - it is an accessibility thing, I don't need it but anyone who, use any screenreader, I guess dropbox needs to communicate there.

a11y is broken with firejail anyway AFAIK because a11y uses a different a11y-bus which we never handle.

whatever dropbox requested it looks legit to me, if I block any of that dbus, dropbox will lose some functionality.

Yes, however at firejail we have a opt-in user base and also look at the treat of. Meaning if the about dialog, which is almost never opened by users, requires a dangerous permission we might decide that a broken about dialog is fine if it makes the sandbox tighter.

I am still concerned about that wildcard, is any way I can know if I can reduce list of ownership.

Not really. If the specification is implemented correctly you need to grand ownership of org.kde.* ¹ and if you have two or more programs that add a tray icon they can conflict and cause strange bugs. Short: Bad API.

¹ actually only subpatters of it but xdg-dbus-proxy can only filter at dot granularity