AppArmor Denial for bluez NewConnection DBus call to a Serial Port provider

snapd
1

While doing some Bluetooth Serial Port Profile (SPP) testing on Ubuntu Core this morning, I found that bluez was prevented from invoking the org.bluez.Profile1.NewConnection method on a registered external profile.

Here’s the AppArmor denial:

Sep 25 11:10:40 1K5JB02 bluetoothd[1538]: Serial Port replied with an error: org.freedesktop.DBus.Error.AccessDenied, An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.4" (uid=0 pid=1538 comm="/snap/bluez/129/usr/lib/bluetooth/bluetoothd -E “) interface=“org.bluez.Profile1” member=“NewConnection” error name=”(unset)" requested_reply=“0” destination=":1.19" (uid=0 pid=2866 comm="./btspp ")

And for those interested in the code which implements the external profile, see my example code on github.

The code in question (btspp) was not being run from a snap, it’d just been copied to the device and run with sudo.

2

What is the apparmor denial?

3

Ah, looks I grabbed the wrong log message… Here it is:

Sep 25 12:05:01 1K5JB02 kernel: [ 7626.663639] audit: type=1107 audit(1506355501.884:276): pid=1466 uid=100 auid=4294967295 ses=4294967295 msg='apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/bluetooth/profile/serial_port" interface=“org.bluez.Profile1” member=“Release” mask=“send” name=":1.24" pid=1538 label=“snap.bluez.bluez” peer_pid=2995 peer_label=“unconfined”

4

Thanks, I’ll take a look at this. Sorry for the delay.

5

Looks like the problem is a bit larger in scope, as there are number of DBus interfaces defined by bluez which are meant for implementation by external applications. BLE was the first to come to mind.

The top level bluex DBus API documentation can be found here:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc

In particular we should review:

6

https://github.com/snapcore/snapd/pull/4097 should have a fix for this. I requested it for 2.29.