Fine-grained dbus policy for applications

[Alexander Larsson]

On Fri, 2020-12-04 at 19:36 -0800, Dylan McCall wrote:
> I am working on a flatpak for an application which needs to interact
> with a dbus service with a large number of interfaces. The
> application only needs to use with a small amount of the stuff
> exposed by this service, so using --talk-
> name=scary.service.with.lots.of.power in flatpak-build-finish is not
> ideal.
> 
> For what it's worth, I do intend to contribute a portal to avoid
> using the big scary service, but there other flatpak applications
> which talk with dbus services in this way and portals are kind of a
> piece-meal solution. (Depending on the specificity of a given
> problem, I dare say they might not even apply in every case, although
> they are effective most of the time).
> 
> So, is there a way to set a more fine-grained dbus policy in a
> flatpak manifest? This would allow me to do the next best thing in
> lieu of a portal. I see xdg-dbus-proxy has a mechanism for more
> specific rules beyond "talks to name"
> (https://github.com/flatpak/xdg-dbus-proxy/blob/master/flatpak-proxy.c#L517-L604
> ). I see how this is used for built in flatpak things, and how I
> assume it could fit into flatpak_context_to_args and
> flatpak_context_add_bus_filters
> (https://github.com/flatpak/flatpak/blob/master/common/flatpak-context.c#L1982-L2073
> ).
> 
> I am wondering if there is an argument to be made for adding
> something like a --call=NAME=RULE option to flatpak-build-finish, or
> extending the syntax for --talk-name with something like
> --talk-name=com.example.Service at com.example.Interface.Method@/com/exa
> mple/object.
> 
> And also, of course, I am also wondering if this argument has already
> happened :)

While the internals of the proxy allows more power (which is mainly
required for the a11y-bus and the portals handling) this is not
currently exposed to users. There are a few reasons for this. 

First of all we want to eventually move the filtering to dbus-daemon
itself to avoid the performance hit of the proxy (see e.g.
https://gitlab.freedesktop.org/dbus/dbus/-/issues/185). This means any
additions to the requirement for the filtering language needs to be
very carefully thought out in terms of performance and implementability
in all codebases.

Secondly, the flatpak permissions are basically show to the user as-is
and the user is then asked to "ok" or "deny" it. A GUI frontend can try
to prettify it as well as it can, but given the already complex format
that is not really an easy task. Adding more complexity to this is not
really going to help actual security, it will just make flatpak
permissions an opaque useless blob that everyone clicks ok to. 

Third, to see whether a fine grained operation like a particular method
call is safe is *far* from trivial. For instance, you need to do a
code-inspection of all the dbus message routing in the server to make
sure the call is 100% safe. This is not something we can expect users
to to, and pretending something helps when it doesn't really is just
security theater and should be avoided.