Comment 33 for bug 306362

Revision history for this message
In , Colin Walters (walters) wrote :

Proposed text of mail announcement:

Subject: [CVE-2008-4311] DBus 1.2.6

A new security release of DBus is now available:

http://dbus.freedesktop.org/dbus/releases/dbus-1.2.6.tar.gz

This release contains a (partial, see below) fix for: https://bugs.freedesktop.org/show_bug.cgi?id=18229

== Summary ==

Because of a mistake in the default configuration for the system bus (system.conf), the default policy for both sent and received messages was effectively *allow*, and not deny as stated.

This release fixes the send side permission, but does not change the receive. See below for more details.

== Available workarounds ==

It is possible to add explicit <deny> rules to existing policy files, and in fact many have these already.

== Mitigating factors ==

There are three important mitigating factors.

* First, in an examination of a Fedora 10 system, many services (though not all, see below) contained explicit <deny> rules. These deny rules did (and continue to) operate as expected.

* Second, an increasing trend has been for core system services to use PolicyKit, or otherwise do security checks on the service side. Any system which relies on PolicyKit is unaffected by this flaw.

* Third, the SELinux DBus support is not affected by this flaw.

Now, as mentioned above this fix is partial. DBus has two kinds of policy permissions, send and receive. Generally speaking, the send side permission is much more important. However, DBus has supported receive side permissions for a few reasons, among those are:

* Ensuring signals containing sensitive data aren't visible by unexpected processes
* A way for processes to "second-pass" filter messages before they reach their C code; however, what one can do in the policy language is relatively limited, and something like PolicyKit (or just manual service-side permission checks) remain a better way to do this.

For compatibility reasons, this release only fixes the send-side permission check, and not receive. A greater number of services will need to be updated for a future tightening of the receive permission.

We are as yet unsure when (and in fact, if) the receive permission will be tightened in the DBus 1.2 stable branch. We will gather information about any affected programs and make a final determination at in the near future.

For now, it is suggested to use explicit <deny> rules for receive side.