How do I fix bluetooth permissions after last dbus update

English Hardware
1

I made the big mistake of updating dbus on my SuSE 11.0 to version 1.1.1-15.4-x86_64. Result was that everything which was previously running perfectly on bluetooth failed (mouse, mobile phones etc.)

I noticed a flood of the following messages in /var/log/messages

Mar 20 00:03:23 pollux dbus-daemon: Rejected send message, 1 matched
rules; type=“method_call”, sender=":1.9" (uid=0 pid=2632
comm="/usr/sbin/hcid -x -s -f /etc/b
luetooth/hcid.conf “) interface=“org.bluez.Database”
member=“RequestAuthorization” error name=”(unset)" requested_reply=0
destination=“org.bluez” (uid=0 pid=2632
comm="/usr/sbin/hcid -x -s -f /etc/bluetooth/hcid.conf "))

And have since spent about three hours trying to fix /etc/dbus-1/ system.d/bluetooth.conf with no success. In the meantime I have reverted to the old dbus from the install CD.

So, what permissions/rules do I have to change to get bluetooth working again with the new dbus?

Currently the bluetooth permissions look like (the default)
<busconfig>

<!-- …/system.conf have denied everything, so we just punch some holes →

<policy user=“root”>
<allow own=“org.bluez”/>
</policy>

<policy at_console=“true”>
<allow send_destination=“org.bluez.Manager”/>
<allow receive_sender=“org.bluez.Manager”/>

&lt;allow send_path="/org/bluez"/&gt;

&lt;allow send_destination="org.bluez.Adapter"/&gt;
&lt;allow receive_sender="org.bluez.Adapter"/&gt;

&lt;allow send_destination="org.bluez.Service"/&gt;
&lt;allow receive_sender="org.bluez.Service"/&gt;

&lt;allow send_destination="org.bluez.Database"/&gt;
&lt;allow receive_sender="org.bluez.Database"/&gt;

&lt;allow send_destination="org.bluez.Security"/&gt;
&lt;allow receive_sender="org.bluez.Security"/&gt;

</policy>

</busconfig>

2

I stumbled upon this permission problem yesterday. To fix it, I tried adding the following line (in bold) in /etc/dbus-1/system.d/bluetooth.conf
<allow send_destination=“org.bluez.Adapter”/>
<allow receive_sender=“org.bluez.Adapter”/>
** <allow send_type=“method_call”/>**
It worked. Hope it’ll also work for you.

3

Hello!

Just a quick note to say thanks! Your fix worked for me, so my Bluetooth mouse is back in business.

An open question: I read about the dbus update, saw the notice that said some things might need to be reconfigured, and then pressed update anyhow. There was no info about what might need to be configured, or how, but what choice did I have except to leave the vulnerability in place. Did I miss the link to the “How to fix devices that break” page: if so please let me know where that link was. Thanks, Tim.

4

I had the same problem with my SUSE 10.3 after the security update of dbus-1 to version 1.0.2-59.8. Before, I had successfully used bluetooth to transmit files from and to my mobile phone via the KDE tools (kbluetooth etc.). After the update, I could not even scan the discoverable bluetooth devices with kbluemon.

I’ve tried the solution suggested by aazikov. Afterwards I could scan for bluetooth devices again. But when establishing the connection between laptop and mobile phone, the password exchange failed, and I got the following error in /var/log/messages:

dbus-daemon: Rejected send message, 1 matched rules; type=“method_call”, sender=":1.9" (uid=0 pid=6788 comm="/usr/sbin/hcid -s -f /etc/bluetooth/hcid.conf “) interface=“org.bluez.PasskeyAgent” member=“Request” error name=”(unset)" requested_reply=0 destination=":1.12" (uid=
1000 pid=6806 comm="kbluetooth "))

In addition, what I did not like in the solution from aazikov was the fact that now every “method_call” from a console user is allowed even if it has nothing to do with bluetooth.

Instead, I got the same result (scanning works, but password exchange fails) without aazikov’s solution, but instead inserting the lines

&lt;allow send_destination="org.bluez"/&gt;
&lt;allow receive_sender="org.bluez"/&gt;

after <policy at_console=“true”>. (I did this because in the error message cited by cfgardiner as well as in my original error messages after the update the destination was “org.bluez” which was not listed in the default bluetooth.conf.)

Then, for the password exchange, I noticed that the rejected send message cited by me above originated not from the console user (pid=1000) but from root (pid=0). So even root seems to lack the rights to send a message like this. The only way I found for allowing it was to use the interface. So I inserted two lines in the root section of bluetooth.conf:

<policy user=“root”>
<allow own=“org.bluez”/>

&lt;allow send_interface="org.bluez.PasskeyAgent"/&gt;
&lt;allow receive_interface="org.bluez.PasskeyAgent"/&gt;

</policy>

After this insertion and a restart, now bluetooth works for me again: scanning for devices, connecting and password exchange, file transfers, and all this in both directions between laptop and mobile phone.

I don’t know much of all these configurations. I just read the man page of dbus-daemon and solved my problem on a trial-and-error basis. So, if anybody reads this posting who knows better, please comment on whether my solution or the other one make sense or opens new security holes. I would also warmly welcome a general update to bluez in order to solve this problem for all SUSE users.

Best regards, Bernd

5

Today (March 25, 2009) I got another security update from opensuse for bluez-utils (bluez-utils-3.18-13.4). This update changes the config file /etc/dbus-1/system.d/bluetooth.conf such that it allows for (probably) most bluetooth connections through dbus.

But still, with this update, the password exchange between my laptop and mobile phone fails.
So I inserted by hand another line into bluetooth.conf, and now it works again, as after my previous suggestion from yesterday.

The new <policy> sections in /etc/dbus-1/system.d/bluetooth.conf after the security update are as follows, with my inserted line in red italic face:


  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>
    <allow send_interface="org.bluez.Agent"/>
    *<allow send_interface="org.bluez.PasskeyAgent"/>*
  </policy>

  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>

  <policy context="default">
    <deny send_destination="org.bluez"/>
  </policy>

(This is complete. It is much shorter as the old version.)

Best regards,
Bernd