D-Bus Policy needs checking

Bug #318757 reported by Scott James Remnant (Canonical)
Affects Status Importance Assigned to Milestone
knetworkmanager (Debian)
Fix Released
knetworkmanager (Fedora)
knetworkmanager (Ubuntu)
Fix Released

Bug Description

knetworkmanager builds one or more binary packages that contain D-Bus system
bus services. The following were detected:

  kde/network-manager-kde etc/dbus-1/system.d/knetworkmanager.conf

The D-Bus policy needs checking!

It was discovered that the default policy of the D-Bus system bus was
not as was expected, due to a quirk of the language. In fact, whereas
the default policy was supposed to have been that messages would not be
allowed by default, the default was in fact that messages _were_

CVE-2008-4311 was issued, and a new release of D-Bus was updated to
correct the default policy to be deny-by-default.


It was quickly discovered that the policy files shipped by most services
no longer worked, and that many were (inadvertently, perhaps) relying on
the misconfiguration of the daemon.

A new version of D-Bus has been uploaded to jaunty co correct this.

Please read the following carefully to assist with updating the

The default policy of the D-Bus system bus is:

 - Name ownership is DENIED by default.

 - Method calls are DENIED by default.

 - Replies to method calls, including errors, are PERMITTED by default.

 - Signals are PERMITTED by default.

Therefore each service MUST, in its policy configuration:

 - Permit an appropriate user to own the name it wishes to claim:

        <policy user="example">
            <allow own="com.ubuntu.Example" />

 - Allow method calls to be made on objects it exports, for particular
   users. This may be done in a number of different ways.

   You may simply allow all method calls to your claimed name:

        <policy context="default">
            <allow send_destination="com.ubuntu.example" />

   You may allow method calls to particular interfaces you export,
   especially useful if you have privileged and non-privileged

        <policy context="default">
            <allow send_destination="com.ubuntu.example"
                   send_interface="com.ubuntu.Example" />

        <policy user="root">
            <allow send_destination="com.ubuntu.example"
                   send_interface="com.ubuntu.Example.System" />

    *IMPORTANT* you MUST include send_destination on ALL allow or deny
    tags. Omitting it is a SERIOUS bug!

                <!-- !! SERIOUS BUG !! -->
                <allow send_interface="x.y.z" />

        This allows any service to receive method calls of the given
        interface, not just your own service!

        It also implicitly allows any service to receive method calls
        with no interface specified, in case they match this interface!

        Using the above means you are potentially allowing exploiting of
        a different service. DO NOT DO IT!

                <!-- !! SERIOUS BUG !! -->
                <deny send_interface="x.y.z" />

        This denies all services from receiving method calls of the
        given interface, not just your own service! It also implicitly
        denies all services from receiving method calls with no
        interface specified. DO NOT DO IT!

 - You must allow standard interfaces as well, such as Introspection and

        <policy context="default">
            <allow send_destination="com.ubuntu.example"
                   send_interface="org.freedesktop.DBus.Introspectable" />
            <allow send_destination="com.ubuntu.example"
                   send_interface="org.freedesktop.DBus.Properties" />

 - You should not normally allow receipt of any messages sent from your
   interface, this is also the default.

   (ie. remove any lines of the form <allow receive_*>)

 - You do not normally need to deny any messages, this is the default.

   (ie. remove any lines of the form <deny...>)

You should fully test the service with the new D-Bus after updating the
policy, you'll need to restart the bus daemon for that (it's probably
easier to reboot).

If messages are being denied, it will be logged in /var/log/auth.log as

Dec 19 14:17:53 space-ghost dbus: Rejected send message, 1 matched
rules; type="method_return", sender=":1.26" (uid=0 pid=2966
comm="/usr/libexec/nm-dispatcher.action ") interface="(unset)"
member="(unset)" error name="(unset)" requested
_reply=0 destination=":1.18" (uid=0 pid=2806 comm="NetworkManager

Be aware that a denied message may still happen if you have other
invalid policy installed (such as those which don't qualify allow/deny
rules with the destination!). Take the opportunity to fix all you see.

Tags: dbus-policy
Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Recent fix of the DBUS default policy for system bus:

seems to uncover a bug in knetworkmanager's default DBUS policy. The policy permits root user to send requests to org.freedesktop.NetworkManagerSettings, though service name registered by knetworkmanager is org.freedesktop.NetworkManagerUserSettings.

Bit more details from the original reporter can be found in bug #475111.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Created attachment 326289
Possible new policy file

Tries to follow some recommendation mentioned here:

Loosely based on nm-applet.conf, but there are few differences:
- it keeps .NetworkManagerInfo, not sure whether it's needed
- it allows at_console users to use .NetworkManagerSettings.Secrets interface
- no access for context="default" users (rely on deny now really used by default)

I played with it a bit on one test system with wired connection only. I can switch to DHCP config fine, but switch to static IP config has no effect. Also tried with the configuration that should be close to the default config prior to dbus 1.2.6, and static IP config does not work either. So not sure if this is actually a policy flaw... Can anyone give it a try on system with some configured wireless connection as well? Stefan, does this address your problem?

Revision history for this message
In , Michael (michael-redhat-bugs) wrote :

I tried your proposed policy file, and it looks like it isn't simply a matter of changing the send_destination from NetworkManagerSettings to NetworkManagerUserSettings and deleting the default context. With your policy file, I get the following errors from NetworkManager:

Dec 11 18:14:54 lucy NetworkManager: <WARN> connection_get_settings_cb(): connection_get_settings_cb: Invalid connection: 'NMSettingIP4Config' / 'addresses' invalid: 1
Dec 11 18:14:59 lucy NetworkManager: <WARN> wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/Connection/1 failed to activate (timeout): (0) Connection was not provided by any settings service

I have a static IP configuration, and used knetworkmanager to set it up.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package knetworkmanager - 1:0.7svn864988-0ubuntu5

knetworkmanager (1:0.7svn864988-0ubuntu5) jaunty; urgency=low

  * debian/patches/ubuntu_dbus_policy.patch:
    - Patch from RedHat: #475468 to (hopefully) fix D-Bus policy.
      LP: #318757.

 -- Scott James Remnant <email address hidden> Mon, 19 Jan 2009 15:46:43 +0000

Changed in knetworkmanager:
status: New → Fix Released
Changed in knetworkmanager:
status: Unknown → In Progress
Revision history for this message
In , Steven (steven-redhat-bugs) wrote :

Any movement on this issue, or is it still an issue?

Revision history for this message
In , Steven (steven-redhat-bugs) wrote :

Since there has been no response within the past 30 days going to close this as INSUFFICIENT DATA.

Changed in knetworkmanager (Fedora):
status: In Progress → Invalid
Revision history for this message
In , Kevin (kevin-redhat-bugs) wrote :

D-Bus was reverted in F10, and knetworkmanager was obsoleted by kde-plasma-networkmanagement in F11.

Changed in knetworkmanager (Debian):
status: Unknown → Fix Released
Changed in knetworkmanager (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.