Summary: SELinux is preventing /usr/sbin/bluetoothd "read" access . Detailed Description: SELinux denied access requested by bluetoothd. It is not expected that this access is required by bluetoothd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:bluetooth_t:s0-s0:c0.c1023 Target Context system_u:object_r:unlabeled_t:s0 Target Objects None [ socket ] Source bluetoothd Source Path /usr/sbin/bluetoothd Port <Unknown> Host (removed) Source RPM Packages bluez-4.64-1.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-51.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.36-rc3-wl+ #8 SMP Wed Sep 1 15:52:26 EDT 2010 x86_64 x86_64 Alert Count 3 First Seen Mon 13 Sep 2010 02:21:08 PM EDT Last Seen Mon 13 Sep 2010 02:22:14 PM EDT Local ID 5c68de14-dee2-4edc-888f-725e80863975 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1284402134.281:250): avc: denied { read } for pid=1584 comm="bluetoothd" scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket node=(removed) type=SYSCALL msg=audit(1284402134.281:250): arch=c000003e syscall=45 success=no exit=-13 a0=18 a1=7fffeb57af80 a2=5 a3=2 items=0 ppid=1 pid=1584 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="bluetoothd" exe="/usr/sbin/bluetoothd" subj=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 key=(null) Hash String generated from catchall,bluetoothd,bluetooth_t,unlabeled_t,socket,read audit2allow suggests: #============= bluetooth_t ============== allow bluetooth_t unlabeled_t:socket read;
Looks like a kernel issue or a problem with a kernel device driver.
*** Bug 633426 has been marked as a duplicate of this bug. ***
John, do you have a reproducer? And unlabeled socket isn't supposed to be possible (it's always a kernel bug of one sort or another) so I'm wondering where this socket came from.....
Attempting to send a pic from my phone over Bluetooth, but even the initial connection attempt is rejected. Seems to be 100% re-creatable here -- FWIW, this is a wireless-testing kernel based on 2.6.36-rc4. 'setenforce 0' allows the connection to proceed, of course. IIRC after the original report I was able to go back to a current Fedora kernel (not sure if 2.6.33- or 2.6.34-based) and proceed w/o incident. So, possibly an upstream regression?
I wouldn't surprise me. socket labeling is done in the kernel by making calls to security_socket_post_create() from sock_create_lite() or __sock_create(). If the bluetooth stack changed to not call these functions we could get into this situation. This'll be fun to try to find....
OK, so this works fine w/ kernel-2.6.34.6-54.fc13.x86_64. The earliest kernel I have laying around that shows this problem calls itself "2.6.35-wl+", but the Bluetooth bits in there are probably more like what is in 2.6.36. So, at least you have a little time before this actually ends-up in a real Fedora kernel... :-)
*** Bug 641513 has been marked as a duplicate of this bug. ***
I'm confirming the same with bluetooth mouse which is no longer recognised correctly. When I do bluetooth pairing cycle it connects to the system and works OK. Mouse then stays connected as long as the system is not suspended or rebooted or the mouse is switched off. Oct 16 14:21:34 XXXXX kernel: [ 2723.286814] type=1400 audit(1287231694.156:20068): avc: denied { getopt } for pid=1285 comm="bluetoothd" scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket Oct 16 14:21:49 XXXXX kernel: [ 2738.874267] input: Logitech Bluetooth Mouse M555b as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/bluetooth/hci0/hci0:43/input13 Oct 16 14:21:49 XXXXX kernel: [ 2738.883516] generic-bluetooth 000X:XXXX:XXXX.XXXX: input,hidraw0: BLUETOOTH HID v4.16 Mouse [Logitech Bluetooth Mouse M555b] on 00:XX:XX:XX:XX:XX kernel 2.6.36-0.39.rc8.git0.fc15.x86_64
Same problem to transfert picture from phone to host over bluetooth : - work fine with kernel-2.6.35.6-46 - selinux error with kernel kernel-2.6.36-1 Problem is 100% reproductible.
*** Bug 646542 has been marked as a duplicate of this bug. ***
I have similar issue (running kernel 2.6.36.1-10.fc15.x86_64 on f13) I see this in logs: Nov 29 19:51:02 lap1 setroubleshoot: SELinux is preventing /usr/sbin/bluetoothd "getopt" access . For complete SELinux messages. run sealert -l 31836b48-2806-449c-a54f-220757a9497e Nov 29 19:51:35 lap1 bluetoothd[1687]: getsockopt(L2CAP_OPTIONS): Permission denied (13) Nov 29 19:51:35 lap1 bluetoothd[1687]: getsockopt(L2CAP_OPTIONS): Permission denied (13) And this sealert: Summary: SELinux is preventing /usr/sbin/bluetoothd "getopt" access . Detailed Description: SELinux denied access requested by bluetoothd. It is not expected that this access is required by bluetoothd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Additional Information: Source Context system_u:system_r:bluetooth_t:s0-s0:c0.c1023 Target Context system_u:object_r:unlabeled_t:s0 Target Objects None [ socket ] Source bluetoothd Source Path /usr/sbin/bluetoothd Port <Unknown> Source RPM Packages bluez-4.64-1.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-73.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Platform Linux hx.sapience.com 2.6.36.1-10.fc15.x86_64 #1 SMP Mon Nov 29 14:41:22 UTC 2010 x86_64 x86_64 Alert Count 12 First Seen Mon Nov 29 19:50:26 2010 Last Seen Mon Nov 29 21:19:22 2010 Local ID 31836b48-2806-449c-a54f-220757a9497e Line Numbers node=hx.prv.sapience.com type=AVC msg=audit(1291083562.766:32696): avc: denied { getopt } for pid=1687 comm="bluetoothd" scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket node=hx.prv.sapience.com type=SYSCALL msg=audit(1291083562.766:32696): arch=c000003e syscall=55 success=no exit=-13 a0=1a a1=6 a2=1 a3=7ffff4cc07d0 items=0 ppid=1 pid=1687 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="bluetoothd" exe="/usr/sbin/bluetoothd" subj=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 key=(null)
Is there any progress about this entry ? Is there any solution to run kernel 2.6.36 on Fedora 14 and use bluethooth ?
*** Bug 669447 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Seems to be working for me, now on a 2.6.39-based kernel...