[ANNOUNCE] D-Bus Broker Project

[Thiago Macieira]

On Thursday, 7 September 2017 13:26:01 -03 David Herrmann wrote:
> > How would this affect your solution? Suppose a malicious program makes a
> > call which results in a system daemon sending a series of directed
> > signals back at the caller. Those should be accounted to the caller, not
> > the system daemon.
> In dbus-daemon(1), those messages are accounted on the sender of the
> signal, so are they in dbus-broker(1). 

In one of the security entries in bugzilla, I proposed changing this and 
accounting to the non-privileged client.

> Those messages have never been
> considered solicited. Hence, there has always been the issue of
> malicious peers triggering those messages without dispatching them.
> 
> In my opinion, those APIs should take object-paths as input, to
> describe the new subscriber. So image you want to subscribe to
> device-events, you would call:
> 
>     SubscribeDevice(o device, o subscriber, ...)
> 
> The subscriber object-path would then be used in the *directed*
> signals, to allow the caller to install matches on them before
> actually subscribing. This has many more benefits, btw. For instance,
> you can cancel your subscription before the subscribe call returns
> (because you already know the object-path of the subscription).

This has the drawback that the client needs to guess an object path on the 
service that is unique and not in use by some other client. That means the 
call may fail because of a collision. The client now needs to have code to 
handle this and re-issue the call with a new path.

This also means the service needs to keep a dictionary to map from the 
arbitrary name provided by the client to the internal object, whereas before 
it could just use some direct identifier (like an index in an array).

> I know, this is not how those APIs were designed in the past, and we
> are still supporting all this. But if you want directed signals to be
> solicited, you need to install a match. dbus-daemon(1) has no policy
> on those, so we cannot just mark them solicited.

It may get one.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center