Does this D-Bus change affect us? (Fwd: New D-Bus Uploaded)

[Scott Ritchie]

This email was just sent to the Ubuntu developer list about a change to
D-Bus security in 9.04 -- do I need to create a D-Bus .conf file for
Wine, or will the default policy suffice for us?

Thanks,
Scott Ritchie

Scott James Remnant wrote:
> If your package contains a D-Bus system bus service, you need to pay
> attention!
> 
> 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.
> 
> 
> We've audited the system bus services shipped in Ubuntu, and are
> confident that there is no security exploit.  Those services exporting
> privileged methods either have sufficient "deny" rules, or use PolicyKit
> for authorisation.
> 
> For this reason, and due to the large potential for regressions, we've
> opted not to release a security update for previous Ubuntu versions.  We
> may still do so if we discover a potential for exploit.
> 
> 
> However this is a bug, and I've uploaded a new version of D-Bus to
> jaunty that corrects it.  I've filed bugs on all packages that appear to
> ship a D-Bus system bus service (those with /etc/dbus-1/system.d/*.conf
> files), but I may have missed some.  I'd appreciate your help tracking
> down any I've missed, and updating all of the packages.
> 
> 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.
> 
> Scott
>