Submitted by Colin Walters @walters

Assigned to Havoc Pennington

Link to original bug (#18961)

Description

Created attachment 20913 don't process deny rules if interface doesn't match

There is a flaw (or at least, problematic behavior) in the current policy logic that causes nondeterminism. This is not a security flaw per se, more of a reliability flaw because it causes denials where they were not intended. This flaw mirrors CVE-2008-0595 (http://lists.freedesktop.org/archives/dbus/2008-February/009401.html). The problem stems from rules of the form:

File A:

<policy context="default">
  <allow send_destination="com.foo.MyService"/>
</policy>

File B:

<policy context="default">
  <allow send_destination="org.foo.Bar"/>
  <deny send_interface="org.foo.Bar.Secure"/>
</policy>

This looks innocuous enough at first (as all these rules do); clearly the intent of the second rule is to lock down access to just part of org.foo.Bar. But it breaks the case of messages sent with no interface to the com.foo.MyService: depending on include ordering

The no-interface case happens in dynamic language scripts like Python typically.

Tracing the logic in policy.c, what happens when a message is sent with no interface is that we see the rule has an interface, then fall into the logic:

      if ((no_interface && rule->allow) ||
           (!no_interface && 
            strcmp (dbus_message_get_interface (message),
                    rule->d.send.interface) != 0))
        continue;

So we're processing a deny rule, with no interface, and this logic does not match. Thus we hit the rule, and the default becomes deny. If we happened to process the rules from the other file first, the message will be spuriously denied.

Patch 20913, "don't process deny rules if interface doesn't match":
dbus-policy.patch

Version: 1.5