Using BLE MIDI devices on Fedora 41 is not possible, because the selinux policy prevents communication between bluetoothd and pipewire user processes. Connecting a device makes it appear in Pipewire, but trying to use it causes bluetoothd to be terminated, apparently due to signal from dbus-broker, which then disconnects all Bluetooth devices. This communication uses the org.bluez.Gatt* DBus API, which involves passing file descriptors from BlueZ to user process (for client mode) and from user process to BlueZ (for server mode). The sockets passed are created by socketpair() e.g. for client mode here, and passed to Pipewire via DBus: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-client.c?id=f863d0116d6271585c2521ff18447c95d95f82fd#n1195 Reproducible: Always Steps to Reproduce: 1. Connect BLE MIDI device: $ bluetoothctl [] scan on [] pair 74:7A:90:AA:BB:CC 2. Device appears in Pipewire: $ pw-cli ls Node | grep bluez_midi.74 node.name = "bluez_midi.74_7A_90_AA_BB_CC" 3. Try to connect device to midi synth: $ pw-jack fluidsynth -a pipewire -m jack -q -i -s & $ pw-link bluez_midi.74_7A_90_AA_BB_CC:out fluidsynth-midi:midi_00 Actual Results: Device disconnects and reconnects, no link to synth is created. In journalctl -u bluetooth, one can see that bluetoothd restarts when pw-link runs. Expected Results: bluetoothd should not be terminated, and selinux should allow the connection. The following makes it work: $ setenforce 0 so it is selinux related. The following selinux rules also make it work: $ cat <<EOF > midigatt.cil (allow bluetooth_t unconfined_t (unix_stream_socket (read write))) (allow system_dbusd_t bluetooth_t (unix_stream_socket (read write))) EOF $ sudo semodule -i midigatt.cil See also: https://github.com/fedora-selinux/selinux-policy/issues/1458 (On Fedora 41, I'm no longer seeing the auditd log messages reported in the above link, maybe the logging configuration changed.)
I am not an selinux maintainer, but, for completeness, it would be very useful to report any AVCs that occur when you attempt to use bluetooth: Reboot. Run your reproducer. $ sudo ausearch -i -ts boot -m avc,user_avc,selinux_err,user_selinux_err > (On Fedora 41, I'm no longer seeing the auditd log messages reported in the above link, maybe the logging configuration changed.) That can occur if the AVCs occur before auditd starts, in which case the AVCs will be recorded on the journal: $ journalctl --no-hostname -b | fgrep -i AVC Another explanation is that there is a dontaudit rule enabled: $ whatis -w \*dontaudit\* semanage-dontaudit (8) - SELinux Policy Management dontaudit tool
(In reply to pav from comment #0) > (allow bluetooth_t unconfined_t (unix_stream_socket (read write))) > (allow system_dbusd_t bluetooth_t (unix_stream_socket (read write))) With selinux-policy-41.26-1.fc41.noarch: $ sesearch -A -s bluetooth_t -t unconfined_t -c unix_stream_socket [no matches] $ sesearch -A -s system_dbusd_t -t bluetooth_t -c unix_stream_socket allow system_dbusd_t bluetooth_t:unix_stream_socket connectto;
Please disable any custom selinux modules before reproducing: $ sudo semodule --disable my-custom-module Verify: $ sudo semodule -lfull | fgrep my-custom-module Documentation: $ whatis semodule semodule (8) - Manage SELinux policy modules. That is in response to this: https://github.com/fedora-selinux/selinux-policy/issues/1458#issuecomment-1315907709
The above reproducer was in a fresh Fedora Workstation 41 installation, with only fluidsynth + pw-jack installed manually. It can be reproduced in fresh Fedora Workstation 41 base installation, out of the box with no changes made. Step 3. above can be replaced by: 3. Try to connect device to some midi port: $ pw-link bluez_midi.74_7A_90_AA_BB_CC:out "Midi-Bridge:Midi Through:(playback_0) Midi Through Port-0" as it doesn't matter which midi port the bluetooth device is connected to. ---- If you don't have BLE MIDI equipment, you can make a Fedora installation BLE MIDI device by: Edit /etc/bluetooth/main.conf, add "ControllerMode=le", systemctl restart bluetooth $ bluetoothctl [] advertise on and then pair and connect from another computer. ---- Looks like Fedora Workstation 41 has dontaudit rules enabled by default which silences the relevant AVC warnings. After: $ sudo semanage dontaudit off The reproducer produces: type=PROCTITLE msg=audit(12/04/2024 17:59:11.457:455) : proctitle=dbus-broker --log 4 --controller 9 --machine-id 980f8b7b2b8c41e0b8f3fa0b0ee825a5 --max-bytes 536870912 --max-fds 4096 --max-matc type=SYSCALL msg=audit(12/04/2024 17:59:11.457:455) : arch=x86_64 syscall=recvmsg success=yes exit=310 a0=0x2a a1=0x7fff2a5c0910 a2=MSG_DONTWAIT|MSG_CMSG_CLOEXEC a3=0x10 items=0 ppid=758 pid=765 auid=unset ui d=dbus gid=dbus euid=dbus suid=dbus fsuid=dbus egid=dbus sgid=dbus fsgid=dbus tty=(none) ses=unset comm=dbus-broker exe=/usr/bin/dbus-broker subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(12/04/2024 17:59:11.457:455) : avc: denied { read write } for pid=765 comm=dbus-broker path=socket:[36238] dev="sockfs" ino=36238 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:bluetooth_t:s0 tclass=unix_stream_socket permissive=0 So seems to be the same AVCs as before. ---- The problem here is what changes in selinux-policy are acceptable to make it work, e.g. can we just add the above accept rules, or is something stricter wanted.
Thanks for your detailed report and for the alternative reproducer that doesn't require a MIDI device. > The problem here is what changes in selinux-policy are acceptable to make it work, e.g. can we just add the above accept rules, or is something stricter wanted. I am not an selinux maintainer, so I am only focused on reproducers. However, as noted in Comment 2, this is already permitted with selinux-policy-41.26-1.fc41.noarch: $ sesearch -A -s system_dbusd_t -t bluetooth_t -c unix_stream_socket allow system_dbusd_t bluetooth_t:unix_stream_socket connectto; > Looks like Fedora Workstation 41 has dontaudit rules enabled by default which silences the relevant AVC warnings. This appears to be the relevant dontaudit rule: $ sesearch --dontaudit -s system_dbusd_t -t bluetooth_t -c unix_stream_socket dontaudit domain domain:unix_stream_socket { read write };
I would suggest updating the bug title to be more specific. You can semi-automatically generate such a title by running the "sealert" command corresponding to the AVC in comment 4: $ journalctl --no-hostname -b | fgrep 'sealert -l' $ sealert -l [nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn] | head -1 Alternatively, you can run "sealert" as a GUI app: $ sealert -b
(In reply to pav from comment #4) > If you don't have BLE MIDI equipment, you can make a Fedora installation BLE MIDI device by: > Edit /etc/bluetooth/main.conf, add "ControllerMode=le", systemctl restart ... After attempting to reproduce this, it appears that I will have to get an adapter to test with BLE. In the mean time, can you see any reason why the access that is being denied by selinux only occurs with "le"? ISTM that the behavior should be the same with "bredr". If "le" and "bredr" lead to different behavior, that could indicate a problem with the "bluez" package and not with selinux. For the record: $ rpm -qf /etc/bluetooth/main.conf bluez-5.79-1.fc41.x86_64 This is the default configuration: $ fgrep -n -B3 ControllerMode /etc/bluetooth/main.conf 49-# Restricts all controllers to the specified transport. Default value 50-# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW). 51-# Possible values: "dual", "bredr", "le" 52:#ControllerMode = dual
semanage-dontaudit(8) says: "Policy writers use dontaudit rules to cause confined applications to use alternative paths." So the problem could be with bluetoothd not using an alternative path. That is, bluetoothd isn't handling the selinux denial. For the record: $ fgrep -n ExecStart /usr/lib/systemd/system/bluetooth.service 9:ExecStart=/usr/libexec/bluetooth/bluetoothd
(In reply to pav from comment #0) > ... trying to use it causes bluetoothd to be terminated, ... ... > Expected Results: > bluetoothd should not be terminated, and selinux should allow the connection. ... Please change the component to bluez. bluetoothd should not be terminating in this situation. Do you see any messages from bluetoothd in the journal? If you want to investigate further, this dbus-tools command can be very informative: $ whatis dbus-monitor dbus-monitor (1) - debug probe to print message bus messages See, also: $ whatis busctl busctl (1) - Introspect the bus Especially: $ busctl --help | egrep ' list | monitor ' list List bus names monitor [SERVICE...] Show bus traffic
To use BLE MIDI, you need to enable LE-mode, that's what the setting does. I believe the above information is sufficient.
(In reply to pav from comment #10) > To use BLE MIDI, you need to enable LE-mode, that's what the setting does. I understand that. In Comment 7, I was *documenting* the options for "ControllerMode" in /etc/bluetooth/main.conf so that the rest of the comment would have complete context. Anyway, my Intel NUC 11 has Bluetooth 5.1 and therefore supports BLE.* However, my Android tablet does not see the NUC when the NUC is restricted to "ControllerMode = le". My Sony headphones DO support BLE, but pairing with them does not trigger the AVC. A Linux-compatible Bluetooth adapter is on order (TP-Link UB500). > I believe the above information is sufficient. And I believe that the component should be changed to "bluez". :-) Regardless, I would still like your opinion as to why the AVC occurs with "ControllerMode = le" and not with "ControllerMode = bredr" (if that is true). * Intel Wireless-AC 9462 https://www.intel.com/content/www/us/en/products/sku/125192/intel-wirelessac-9462/specifications.html
Please see the reproducer again: Fedora install *and* a BLE MIDI device is required. A Sony headset is not a BLE MIDI device. If you don't have a BLE MIDI device, and want to use another computer to make one, only then ControllerMode comes in. Anyway, I'll wait maintainer comments.
Does the AVC occur with "ControllerMode = bredr"?
You cannot pair BLE MIDI devices in bredr mode.
(In reply to pav from comment #14) > You cannot pair BLE MIDI devices in bredr mode. Thanks for the clarification. Do you have a BR/EDR MIDI device to test with?
BR/EDR MIDI devices do not exist.
(In reply to pav from comment #16) > BR/EDR MIDI devices do not exist. OK, that would making testing that case difficult ... :-) However, a computer can be configured to reproduce the AVC (Comment 4). Can you reproduce the AVC using BR/EDR mode and a computer, as in Comment 4?
MIDI protocol is LE only. Both sides must have LE mode enabled.
(In reply to pav from comment #18) > MIDI protocol is LE only. Both sides must have LE mode enabled. OK. I was expecting a protocol *stack* with BLE and BR/EDR near the bottom and MIDI near the top. Very strange.
(In reply to pav from comment #0) > This communication uses the org.bluez.Gatt* DBus API, ... The Generic Attribute profile (GATT) supports LE and BR/EDR, so it should be possible to trigger the AVC in BR/EDR mode: Part G. Generic Attribute Profile (GATT) https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-54/out/en/host/generic-attribute-profile--gatt-.html However, this comment in the kernel code you linked suggests otherwise: /* * TODO: Once GATT over BR/EDR is properly supported, we should pass the * correct bdaddr_type based on the transport over which GATT is being * done. */ https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/gatt-client.c?id=f863d0116d6271585c2521ff18447c95d95f82fd#n2433
GATT is mandatory only for LE. BlueZ does not support GATT over BR/EDR, so it is not possible.
This sidetrack has nothing to do with the SELinux issue at hand here, so let's just drop it.
(In reply to pav from comment #21) > GATT is mandatory only for LE. BlueZ does not support GATT over BR/EDR, so it is not possible. That is apparent from the kernel code. However, it should be possible to trigger the AVC in LE mode without referring to MIDI in any way. (In reply to pav from comment #22) > This sidetrack has nothing to do with the SELinux issue at hand here, so let's just drop it. That is not established. AVCs can sometimes expose a bug *elsewhere*, such as in bluetoothd. Comment 0: "... causes bluetoothd to be terminated, apparently due to signal from dbus-broker, ..." Is that speculation or did you try running strace on the two processes?
> However, it should be possible to trigger the AVC in LE mode without referring to MIDI in any way. See https://github.com/fedora-selinux/selinux-policy/issues/1458#issuecomment-1321171305 > > causes bluetoothd to be terminated, apparently due to signal from dbus-broker, ..." > Is that speculation or did you try running strace on the two processes? You can attach gdb to bluetoothd, set a breakpoint on the signal handler `signal_callback`, and observe that the program received signal 15 (SIGTERM). Alternatively in journalctl, when the reproducer is run, you see the message printed by the signal handler, followed by the handler of system DBus disconnection: Dec 06 12:29:57 bluetoothd[185814]: Terminating Dec 06 12:29:57 bluetoothd[185814]: Disconnected from D-Bus. Exiting.
I reproduced the AVC and the bluetoothd restart with a Linux-compatible USB Bluetooth adapter and a *Bluetooth mouse*: $ lsusb -d 0b05:190e Bus 001 Device 006: ID 0b05:190e ASUSTek Computer, Inc. ASUS USB-BT500 https://www.asus.com/us/networking-iot-servers/adapters/all-series/usb-bt500/ $ bluetoothctl devices Device CF:03:19:7C:89:89 BT mouse $ bluetoothctl info CF:03:19:7C:89:89 Device CF:03:19:7C:89:89 (random) Name: BT mouse Alias: BT mouse Appearance: 0x03c2 (962) Icon: input-mouse Paired: yes Bonded: yes Trusted: no Blocked: no Connected: yes WakeAllowed: yes LegacyPairing: no UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb) UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb) UUID: Vendor specific (6e40ff01-b5a3-f393-e0a9-e50e24dcca9e) Modalias: bluetooth:v3938p1065d0100 ManufacturerData.Key: 0x0006 (6) ManufacturerData.Value: 03 00 80 ... AdvertisingFlags: 05 . Battery Percentage: 0x4b (75)
Created attachment 2061680 [details] tail of journal starting with AVC $ head -2 journalctl-2024-12-08-02.txt Dec 08 15:21:54 audit[1184]: AVC avc: denied { read write } for pid=1184 comm="dbus-broker" path="socket:[26085]" dev="sockfs" ino=26085 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:bluetooth_t:s0 tclass=unix_stream_socket permissive=0 Dec 08 15:21:54 bluetoothd[1186]: Disconnected from D-Bus. Exiting. NB: dontaudit rules were disabled. Tested with: $ rpm -q selinux-policy bluez wireplumber pipewire systemd dbus-broker dbus | sort bluez-5.79-1.fc41.x86_64 dbus-1.14.10-4.fc41.x86_64 dbus-broker-36-4.fc41.x86_64 pipewire-1.2.7-1.fc41.x86_64 selinux-policy-41.26-1.fc41.noarch systemd-256.9-2.fc41.x86_64 wireplumber-0.5.5-2.fc41.x86_64 $ uname -r 6.11.10-300.fc41.x86_64
NB: /etc/bluetooth/main.conf did not need to be modified for this test.
Snippet from bluetoothctl session: [BT mouse:/service0001/char0002]# gatt.select-attribute /org/bluez/hci0/dev_DD_07_0E_CA_F7_9F/service002e/char0031 [BT mouse:/service002e/char0031]# gatt.acquire-notify [BT mouse:/service002e/char0031]# [DEL] Media /org/bluez/hci0 [BT mouse:/service002e/char0031]# SupportedUUIDs: 0000110a-0000-1000-8000-00805f9b34fb [BT mouse:/service002e/char0031]# SupportedUUIDs: 0000110b-0000-1000-8000-00805f9b34fb [BT mouse:/service002e/char0031]# Agent unregistered [BT mouse:/service002e/char0031]# [DEL] Controller CC:28:AA:XX:XX:XX bt-test-1 [default]
(In reply to pav from comment #24) ... > Alternatively in journalctl, when the reproducer is run, you see the message printed by the signal handler, followed by the handler of system DBus disconnection: > > Dec 06 12:29:57 bluetoothd[185814]: Terminating > Dec 06 12:29:57 bluetoothd[185814]: Disconnected from D-Bus. Exiting. "Terminating" is not in the full journal: $ egrep -n 'Terminating|Exiting' journalctl-2024-12-08-01.txt # This is the full journal from the test session. 2367:Dec 08 15:21:54 bluetoothd[1186]: Disconnected from D-Bus. Exiting. There must be some difference between our two test cases. Could you post some version info? $ rpm -q selinux-policy bluez wireplumber pipewire systemd dbus-broker dbus | sort $ uname -r
> "Terminating" is not in the full journal: AFAIK this is a timing issue. BlueZ is using signalfd for the signal handler, so it depends on timings whether the mainloop first processes the signal, or the DBus disconnection. If the latter, the process exits right away without seeing the signal (no "Terminating"), if the signal is received first it will wait for SHUTDOWN_GRACE_SECONDS before shutting down ("Terminating" in log). You can comment out the mainloop_quit() in src/main.c:disconnected_dbus to see the signal every time.
Cross-reference reproducer in a VM: Bug 2331485 - SELinux is preventing /usr/bin/dbus-broker from read, write access on the unix_stream_socket unix_stream_socket. [system_dbusd_t -> bluetooth_t with dontaudit rules disabled]
(In reply to pav from comment #30) > > "Terminating" is not in the full journal: > > AFAIK this is a timing issue. BlueZ is using signalfd for the signal > handler, so it depends on timings whether the mainloop first processes the > signal, or the DBus disconnection. If the latter, the process exits right > away without seeing the signal (no "Terminating"), if the signal is received > first it will wait for SHUTDOWN_GRACE_SECONDS before shutting down > ("Terminating" in log). You can comment out the mainloop_quit() in > src/main.c:disconnected_dbus to see the signal every time. Thanks for investigating that: https://github.com/bluez/bluez/blob/5.79/src/main.c#L1319-L1323 Can you determine what process actually sends the SIGTERM signal?
For the record, there are three different bluetooth socket rules: $ sesearch -A -s system_dbusd_t -t bluetooth_t | fgrep socket allow system_dbusd_t bluetooth_t:bluetooth_socket { append bind connect getattr getopt ioctl lock read setattr setopt shutdown write }; [ deny_bluetooth ]:False allow system_dbusd_t bluetooth_t:socket { append bind connect getattr getopt ioctl lock read setattr setopt shutdown write }; allow system_dbusd_t bluetooth_t:unix_stream_socket connectto; $ sudo semodule -lfull | fgrep bluetooth 100 bluetooth pp Tested with: $ rpm -q selinux-policy selinux-policy-41.26-1.fc41.noarch
Cross-reference: Bug 2332148 - There are three different bluetooth socket rules.
This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 41 entered end-of-life (EOL) status on 2025-12-15. Fedora Linux 41 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.