Bug 603729

+++ This bug was initially created as a clone of Bug #566332 +++


Résumé:

SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0.

Description détaillée:

SELinux has denied bluetoothd "read" access to device rfcomm0. rfcomm0 is
mislabeled, this device has the default label of the /dev directory, which
should not happen. All Character and/or Block Devices should have a label. You
can attempt to change the label of the file using restorecon -v 'rfcomm0'. If
this device remains labeled device_t, then this is a bug in SELinux policy.
Please file a bg report. If you look at the other similar devices labels, ls -lZ
/dev/SIMILAR, and find a type that would work for rfcomm0, you can use chcon -t
SIMILAR_TYPE 'rfcomm0', If this fixes the problem, you can make this permanent
by executing semanage fcontext -a -t SIMILAR_TYPE 'rfcomm0' If the restorecon
changes the context, this indicates that the application that created the
device, created it without using SELinux APIs. If you can figure out which
application created the device, please file a bug report against this
application.

Autoriser l'accès:

Attempt restorecon -v 'rfcomm0' or chcon -t SIMILAR_TYPE 'rfcomm0'

Informations complémentaires:

Contexte source               system_u:system_r:bluetooth_t:s0-s0:c0.c1023
Contexte cible                system_u:object_r:device_t:s0
Objets du contexte            rfcomm0 [ chr_file ]
source                        bluetoothd
Chemin de la source           /usr/sbin/bluetoothd
Port                          <Inconnu>
Hôte                         (removed)
Paquetages RPM source         bluez-4.61-1.fc13
Paquetages RPM cible          
Politique RPM                 selinux-policy-3.7.8-11.fc13
Selinux activé               True
Type de politique             targeted
Mode strict                   Enforcing
Nom du plugin                 device
Nom de l'hôte                (removed)
Plateforme                    Linux (removed)
                              2.6.33-0.44.rc8.git0.fc13.i686.PAE #1 SMP Sat Feb
                              13 02:29:36 UTC 2010 i686 i686
Compteur d'alertes            2
Première alerte              mer. 17 févr. 2010 18:14:32 CET
Dernière alerte              mer. 17 févr. 2010 23:55:17 CET
ID local                      5dde3c76-192e-4a71-83f1-ff21a05c2f26
Numéros des lignes           

Messages d'audit bruts        

node=(removed) type=AVC msg=audit(1266447317.685:24188): avc:  denied  { read } for  pid=1497 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=69741 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1266447317.685:24188): arch=40000003 syscall=5 success=no exit=-13 a0=f9aa98 a1=100 a2=0 a3=fae9a0 items=0 ppid=1 pid=1497 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  device,bluetoothd,bluetooth_t,device_t,chr_file,read
audit2allow suggests:

#============= bluetooth_t ==============
allow bluetooth_t device_t:chr_file read;

--- Additional comment from misc on 2010-02-17 18:01:26 EST ---

The rfcomm0 file was created using blueman, and a regular nokia e65 phone, using DUN.

Using restorecon correct the context.

--- Additional comment from dwalsh on 2010-02-17 18:12:17 EST ---

Of blueman is creating the device it needs to make sure the device is properly labeled.  Either need to run restorecon itself or use udev to create the device.

Since blueman is not part of Fedora I have to close this bug as can't fix.

You could either patch blueman to create the device with the right label or use restorecond to watch for the device and fix its label.

If you want to open a bug with blueman, I would work with them to fix their code.

--- Additional comment from misc on 2010-02-17 18:44:13 EST ---

Well, blueman is packaged in fedora. 

And that's not blueman directly that create the rfcomm device, but bluetoothd using dbus or the python api, I am not sure from looking at the code.  Since blueman is not running as root, I doubt it can create the file directly.

However, when trying to reproduce using rfcomm, it work correctly.

--- Additional comment from dwalsh on 2010-02-18 08:44:51 EST ---

Ok, My mistake.  I tried to install blueman but you did not find it.

--- Additional comment from dwalsh on 2010-02-18 08:49:24 EST ---

So the question is who/what creates the /dev/rfcomm0 device?  Is it the kernel/devicedriver, something in bluetooth, or udev?  Whoever created it, created it with the wrong label.

--- Additional comment from dwalsh on 2010-03-05 09:46:52 EST ---

*** Bug 570815 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh on 2010-03-05 09:58:27 EST ---

Eric, could you check if the kernel module is creating the /dev/rfcomm0 device?

--- Additional comment from mgrepl on 2010-03-10 05:59:41 EST ---

*** Bug 572082 has been marked as a duplicate of this bug. ***

--- Additional comment from misc on 2010-04-22 04:54:53 EDT ---

Ok, after reading bluez code, the device is created using a ioctl :

dev = ioctl(sk, RFCOMMCREATEDEV, &req);

And so everything is done in kernel, there is a function  rfcomm_create_dev that does it ( in net/bluetooth/rfcomm/tty.c ). There is no mention of selinux anywhere.

And as I said, if I use rfcomm as root, the device is correctly labeled ( iirc ).

--- Additional comment from dwalsh on 2010-04-22 07:40:40 EDT ---

Eric, shouldn't the kernel be telling udev to create the device?

--- Additional comment from awilliam on 2010-05-19 22:48:13 EDT ---

I´ve just hit a bug which gets called a dupe of this, if you go through two levels of dupes. It happens every time I try to set up Bluetooth DUN via a phone after a clean F13 install, using regular GNOME bluetooth stuff. At the end of the pairing process for the phone there is a box you can check to do the DUN stuff. As soon as I check this, the denial comes up (repeatably).

--- Additional comment from nk on 2010-05-20 03:35:27 EDT ---

Created an attachment (id=415328)
semodule to workaround the problem

--- Additional comment from dwalsh on 2010-05-21 09:55:59 EDT ---

Adam/Nicholas if you look at the device is it labelled device_t?


ls -lZ /dev/rfcomm0

--- Additional comment from nk on 2010-05-21 13:02:43 EDT ---

crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/rfcomm0

--- Additional comment from dwalsh on 2010-05-24 11:36:21 EDT ---

Which is correct.  It looks like we have some kind of race condition, where someone (kernel?) creates the device and then some other process (udev?) comes in and fixes the label.

--- Additional comment from wdc on 2010-06-03 21:51:33 EDT ---

I too am being affected by this bug.  I am using the semodule work-around for now, myself.

Hardware: Lenovo T60p laptop.
Kernel:  2.6.33.5-112.fc13.i686
NetworkManager-0.8.1-0.1.git20100510.fc13.i686
ModemManager-0.3-12.git20100504.fc13.i686