BlueZ DBus APIs pass sockets fds via DBus, and these sockets can be either bluetooth socket or local unix socket.
For example, org.bluez.GattCharacteristic1.AcquireWrite returns an fd which is a unix socket.

Another part of the same API requires a user process to pass the other end fd of a unix socketpair to bluetoothd.

However, it appears currently the SELinux policy allows bluetoothd to pass only bluetooth sockets via DBus, but blocks unix sockets, so parts of the BlueZ API don't work. An attempt to call the "blocked" functions from user process results to bluetoothd getting a SIGTERM, which is a fairly mysterious failure mode. This is probably not intended...

A user process trying to call these APIs results to the following denial in audit.log:

type=AVC msg=audit(1668101138.885:491): avc:  denied  { read write } for  pid=1901 comm="dbus-broker" path="socket:[87824]" dev="sockfs" ino=87824 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0

The necessary access can be allowed by this midigatt.te

allow system_dbusd_t unconfined_service_t:unix_stream_socket { read write };
# On Fedora Server, bluetoothd runs under bluetooth_t, not unconfined_service_t
allow system_dbusd_t bluetooth_t:unix_stream_socket { read write };

Maybe the bluetooth_stream_connect macro needs to allow also the unix_stream_socket type in the same way it allows bluetooth_socket.

One use case here is supporting BLE MIDI in Pipewire, which currently faces this SELinux policy issue.