D-Bus Policy needs checking

[Scott James Remnant (Canonical)]

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

  admin/hal etc/dbus-1/system.d/hal.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_
allowed!

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

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4311

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
configuration.

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" />
        </policy>

 - 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" />
        </policy>

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

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

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

    *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
   Properties:

        <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" />
        </policy>

 - 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
follows:

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
--pid-file=/var/run/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.

[Colin Walters (walters)]

Created an attachment (id=21023)
proposed hal.conf.in

Propose replacing the existing .conf.in with this upstream, moving the other one to hal-nopolicykit.conf.in. (Possibly add a configure option?)

[Colin Walters (walters)]

Ping on this bug - I want to do a new dbus release with logging, and NetworkManager talking to HAL constantly warns about the KillSwitch method.

[Richard Hughes (richard-hughes)]

I think we need to discuss this upstream. I would prefer a much less invasive patch as HAL is in effective feature freeze.

[Colin Walters (walters)]

(Aren't we discussing this upstream now?) Ok, I'll see about putting together a targeted patch.

[Colin Walters (walters)]

Created an attachment (id=21326)
allow introspection and Device.KillSwitch access

This one just allows introspection and Device.KillSwitch access. There may be others.

[Simon McVittie (smcv)]

For reference, this is Debian bug <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510639>; I put some notes and proposed patches there while trying to fix it in the (older?) version used in Debian 5.0.

A perhaps-simpler way to fix NetworkManager's use of hal would be to allow root to access all of hal's functionality, which I've proposed as a patch to the Debian package. Since root is allowed to replace or impersonate hal, being able to access hal seems fairly uncontroversial.

hal also has the bug tracked by <http://bugs.freedesktop.org/show_bug.cgi?id=18961> (send_interface without send_destination) which I've proposed as a patch; it won't apply upstream without minor modification since I applied it after the Debian-specific group-based access control patch, but the changes are hopefully obvious.

According to some quick testing, gnome-power-manager (at least at the version in Debian 5.0) also wants to access the CPUFreq interface, so that should probably be allowed for users who are at_console (or some other suitable access control - in Debian it's the powerdev group, but that's Debian-specific anyway). I also suggested allowing DockStation and WakeOnLan, which seemed in-scope for the Debian powerdev group.

Which other interfaces have I missed, that are "fairly safe" for users with physical access?

[Simon McVittie (smcv)]

This also seems to be https://bugzilla.redhat.com/show_bug.cgi?id=476043

[Scott James Remnant (Canonical) (canonical-scott)]

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

  admin/hal etc/dbus-1/system.d/hal.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_
allowed!

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

    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4311

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
configuration.

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" />
        </policy>

 - 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" />
        </policy>

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

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

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

    *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 stand...

[Launchpad Janitor (janitor)]

This bug was fixed in the package hal - 0.5.12~rc1-0ubuntu7

---------------
hal (0.5.12~rc1-0ubuntu7) jaunty; urgency=low

  * debian/patches/ubuntu_03_dbus_policy.patch, LP: #318746:
    - Always allow D-Bus introspection.
    - Qualify all instances of send_interface with send_destination.
    - Remove confusing and unnecessary receive_* matches: signals and
      expected replies are always allowed.
    - Collapse duplicated policy.
    - Allow the device KillSwitch, CPUFreq, WakeOnLan and DockStation
      interfaces.

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

[Danny Kukawka (danny-kukawka)]

It should be fixed now in git master.

Check: http://cgit.freedesktop.org/hal/tree/hal.conf.in