Bug 603729 - SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0.
SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0.
Status: CLOSED DUPLICATE of bug 575128
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.0
i386 Linux
low Severity medium
: rc
: ---
Assigned To: Eric Paris
Red Hat Kernel QE team
setroubleshoot_trace_hash:fa9a779e21f...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-14 09:00 EDT by Jay Turner
Modified: 2015-01-07 19:17 EST (History)
62 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 566332
Environment:
Last Closed: 2010-08-31 10:50:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jay Turner 2010-06-14 09:00:59 EDT
+++ 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@zarb.org 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@redhat.com 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@zarb.org 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@redhat.com 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@redhat.com 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@redhat.com on 2010-03-05 09:46:52 EST ---

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

--- Additional comment from dwalsh@redhat.com 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@redhat.com on 2010-03-10 05:59:41 EST ---

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

--- Additional comment from misc@zarb.org 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@redhat.com on 2010-04-22 07:40:40 EDT ---

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

--- Additional comment from awilliam@redhat.com 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@r-networks.ru on 2010-05-20 03:35:27 EDT ---

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

--- Additional comment from dwalsh@redhat.com 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@r-networks.ru 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@redhat.com 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@mit.edu 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
Comment 1 Jay Turner 2010-06-14 09:02:29 EDT
I'm seeing the same behavior with RHEL6
kernel-2.6.32-33.el6
bluez-4.57-5.el6
udev-147-2.17.el6
selinux-policy-3.7.19-24.el6
Comment 2 Adam Williamson 2010-06-14 10:48:18 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Eric Paris 2010-08-05 17:04:04 EDT
I'm suggesting this BZ be pushed to 6.1.  From looking at the strace information and comments from users in 566332 it appears this, in and of itself, is not causing the failure of any functionality.  The first open fails, udev then fixes the node, the second open works and the service works.  It might be a bit of a PITA but not a catastrophic lack of functionality.
Comment 5 wdc 2010-08-05 18:02:52 EDT
Note that if RHEL 6.0 synchs up with Fedora the severity of this bug will be much greater.  Under Fedora, rfcomm0 is created on the fly, and then destroyed when the bluetooth setup is taken down.

So it's only a PITA for now.  When rfcomm0 goes dynamic this bug becomes a show stopper.
Comment 9 Eric Paris 2010-08-31 10:50:50 EDT
We  have identified the patch that caused this issue and it was introduced by a udev changed (at the request of SELinux people).  I am going to mark this bug a dupe of the udev bug which introduced the change.  That BZ has been reopened to address this consequence of that request.

*** This bug has been marked as a duplicate of bug 575128 ***

Note You need to log in before you can comment on or make changes to this bug.