D-Bus: Multicast Messages

[David Herrmann]

Hey

We have recently tried to implement client-controlled policies for
D-Bus signals, but ran into several issues on the way. So far, D-Bus
clients can easily control access to Method-Calls, including external
verification like polkit. systemd makes heavy use of this [1] to
provide dynamic access control that extends the static D-Bus policies.
Furthermore, it is becoming increasingly popular to interpret the
D-Bus policies as 3rd-party firewalls, rather than first class access
control [2], thus relying on client access control for security.
However, so far there is no way to apply these controls to
signal-broadcasts.

In D-Bus, signal-broadcasts are inherently global information. A
producer of a signal has no way to control who receives the
information sent. The message is submitted to dbus-daemon and then
forwarded to all interested parties. The only restriction is the D-Bus
policy or MACs. This greatly limits the use-cases for D-Bus signals in
combination with client-side access control.

In particular, if an application provides signals on dynamically
created objects, it is preferable to only forward the signals to
clients who have access to the object. There are plenty of examples
that already do this, using D-Bus directed signals (rather than
broadcasts). This includes systemd-logind controller management, D-Bus
daemon systemd activation, polkit agents, bluez agents, and more.
Hence, I think there is a general use-case for fine-grained
access-control on signals.
Obviously, those are all limited to unicast signals, rather than
broadcast signals. Our aim is to extend this beyond unicasts, using
multicasted signals, so we can implement a subscriber model. For this
we need a concept of multicasts.

A multicast message is distinguished from unicasts by having more than
one destination, thus extending the current detection to this:

    <1 destination: broadcast
    =1 destination: unicast
    >1 destination: multicast

Furthermore, it should be restricted to signals, just like broadcasts are.

The behavior of a multicast message is exactly that of a sequence of
unicast messages, with the exception that it is handled atomically
regarding message-ordering. IOW, the message broker simply forwards a
multicast to each destination, turning each forwarded message into a
unicast. The receiver of a multicast will be unable to distinguish it
from a unicast.

With this in place, the concept of directed signals, as used by the
examples mentioned above, can be extended to full subscription models,
where there can be multiple receivers of a message. Thus, we get
fine-grained control over which peer should be allowed to receive a
signal, while still maintaining global ordering guarantees of D-Bus.

So far, there has been no attempt to implement this. I wanted to get
some feedback first, before looking deeper into this. I haven't
encountered any roadblocks, yet, but I'd be interested in wider review
of this idea.

Thanks
David


[1] https://github.com/systemd/systemd/blob/master/src/shared/bus-util.c#L388
[2] "Access control on the system bus"
    https://smcv.pseudorandom.co.uk/2017/dbus_and_containers/