DBus filtering

[Simon McVittie]

On Tue, 02 Nov 2021 at 23:00:27 +0100, Sergio Costas wrote:
> I've been searching for information about how the session bus is filtered
> for a flatpak application.

What is allowed is described in flatpak-metadata(5) and in
<https://docs.flatpak.org/en/latest/sandbox-permissions.html>,
and can be modified by the sysadmin or user with flatpak-override(1).

For the implementation, the thing to look for in the source code is
references to "xdg-dbus-proxy". Depending on how you built Flatpak, it
might be using a separate system copy of
<https://github.com/flatpak/xdg-dbus-proxy> (as it does in e.g. Debian),
or it might be using its own bundled submodule (as it will usually do if
you built Flatpak from source).

> - Does any flatpak application see all the well-known names in the session
> bus? Only some? Only those defined in a configuration file...?

It can talk to anything matching org.freedesktop.portal.* (a hard-coded
special case for ability to see portals), plus whatever is specifically
allowed by the app's flatpak-metadata(5).

(Strictly speaking, flatpak-metadata(5) as modified by flatpak-override(1).)

> - Does any flatpak application see all the "unique connection" names?

Usually no, it can only see any unique connection names that own one of
the well-known names that it can see.

The usual IP analogy applies here: if well-known bus names are like DNS
names, then unique connection names are like IP addresses. If I configure
an IP firewall to allow access to example.com, what I'm really doing is
allowing access to the IP address of example.com, including any other
services that happen to be hosted on the same IP address. Similarly,
if I configure a Flatpak app to allow access to net.example.MyService,
what I'm really doing is allowing access to the unique name that currently
owns net.example.MyService, including any other D-Bus APIs that happen
to be provided by the same D-Bus connection.

> - Which well-known names are allowed to register a flatpak application?

A Flatpak application is allowed to own well-known names that correspond
to its own Flatpak app-ID (so the Flatpak app com.example.MyApp can own
com.example.MyApp or com.example.MyApp.MyService, but not com.example.Other)
plus anything that is specifically allowed in its flatpak-metadata(5).

(Again, strictly speaking, flatpak-metadata(5) as modified by
flatpak-override(1).)

> - If an application wants to prevent sandboxed flatpak applications to get
> access to its well-known names, does it have to do something?

The control is mostly on the other side: instead of services preventing
Flatpak apps from accessing them, it's Flatpak preventing Flatpak apps
from accessing services.

However, if a Flatpak app is allowed to access a service (for
example a portal), the service can detect which Flatpak app it is from
/proc/$pid/root/.flatpak-info, where $pid can be learned from the message
bus (usually dbus-daemon or dbus-broker) with GetConnectionCredentials().
The service could use that information to reject method calls, if it
wants to.

    smcv