[CVE-2008-4311] DBus 1.2.8

[Colin Walters]

A new release of DBus is now available:

http://dbus.freedesktop.org/dbus/releases/dbus-1.2.8.tar.gz
SHA1: f6a5215b1eb6fee17821beb22f2e934ad383bfbe

This release is a continuation of work on:
https://bugs.freedesktop.org/show_bug.cgi?id=18229

== Overview ==
I think we're finally arriving at general consensus for where the line
for bugs in the core is versus in external programs for this issue.

DBus 1.2.8 has one behavioral change, which is to allow all signals by
default on the system bus. There is also a documentation update for
the system bus:

"Currently, the system bus has a default-deny policy for sending method calls
and owning bus names.  Everything else, in particular reply messages, receive
checks, and signals has a default allow policy."

There are two major things to be aware of, in order of importance:

== Services ==
Now, corresponding with this issue, some services must be updated.  A
tracking bug has been created:
https://bugs.freedesktop.org/show_bug.cgi?id=18980

The above bug is for services which fail with the policy for DBus
1.2.8 (i.e. not 1.2.6).

== <deny send_interface=""/>
Besides services which must be updated to work, there are also
services whose config breaks *other* services or introduces erroneous
permissions.  This kind of flaw is really the fault of the policy
language - it's incredibly easy to introduce these kinds of flaws.  In
general, every rule in a system.d/foo.conf should include
"send_destination".  If it doesn't, it's almost certainly a bug.

The most insidious is this one:

<policy context="default">
  <deny send_interface="org.foo.Iface"/>
</policy>

Effectively, this will deny all messages sent with no interface - even
those *not sent to your service* - as occurs when using e.g. Python
and not using the dbus.Interface cast.  The correct rule looks like
this:

<policy context="default">
  <deny send_destination="org.foo.Service" send_interface="org.foo.Iface"/>
</policy>

Bottom line - use send_destination in *every* rule unless you know
explicitly what you're doing, and avoid putting two services in the
same process (if you do, use PolicyKit).