Re: eavesdrop in dbus policy

On 23/03/15 14:42, Aubert Malek (MM) wrote:
> I just need to understand this. Running the user that uses dbus_daemon
> as root and give it eavesdrop=true causes conflicts with security policy
> but what if I run it as logging for example (usr=logging) and make dbus
> policy changes only for this user (logging). I'll be having this in my
system_local.conf:
> <policy user="logging">
>                 <allow eavesdrop="true"/>
>                 <allow send_destination="*" eavesdrop="true"/> </policy>

I thought that sort of approach might work, but later realised it
didn't, and implemented BecomeMonitor instead.

> You are saying that this shouldn't work. Why shouldn't this work?

The fundamental problem is that a message is only delivered if both of
these are true:

* the sender is allowed to send to the recipient;
* the recipient is allowed to receive from the sender.

<policy user="logging"><allow eavesdrop="true"/> means the (dbus-monitor
that was run by) the "logging" user may receive any message from
anywhere, even if it is considered to be eavesdropping (the message is
not a broadcast and is intended for someone else).

<policy user="logging"><allow send_destination="*" eavesdrop="true"/>
means the logging user may send any message to anywhere (which in
practice probably makes it root-equivalent, a security vulnerability,
unless you are already treating "logging" as root-equivalent) - but this
does not actually do anything to solve your problem, because you're
interested in other things sending messages to logging, and not in
logging sending messages to other things.

<policy user="logging"><allow send_destination="*" eavesdrop="true"/>
does *not* mean other processes are allowed to send messages to the
dbus-monitor that was run by the "logging" user! So you don't get all
the messages.

What you want here is something like this pseudocode:

<policy context="default">
  <allow send_if_recipient_uid_is="logging" eavesdrop="true"/>

but there is no send_if_recipient_uid_is attribute in any current
version of dbus, so you can't do that.

I could have solved this by adding that attribute in a 1.9.x version; if
I'd done that, you still wouldn't be able to eavesdrop on these messages
in dbus 1.8.x. I added BecomeMonitor() instead, because I think that
model is much easier to understand / harder to get wrong.

    S
_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus