Bug 570815 - selinux-policy-targeted doesn't allow /usr/sbin/bluetoothd to access /dev/rfcomm0
Summary: selinux-policy-targeted doesn't allow /usr/sbin/bluetoothd to access /dev/rfc...
Keywords:
Status: CLOSED DUPLICATE of bug 566332
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-05 14:15 UTC by Leonid Kanter
Modified: 2010-03-05 14:46 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-03-05 14:46:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Leonid Kanter 2010-03-05 14:15:08 UTC
Description of problem:

selinux-policy-targeted doesn't allow /usr/sbin/bluetoothd to access /dev/rfcomm0

Version-Release number of selected component (if applicable):

selinux-policy-targeted-3.7.10-3.fc13.noarch

How reproducible:

always

Steps to Reproduce:
1. Right-click on bluetooth icon, select properties, find devices and select your mobile phone
2. Pair it and try to set it up as a dun device
  
Actual results:

SELinux security alert will be produced

Expected results:

Phone should be configured as a DUN device out of the box

Additional info:
localhost setroubleshoot: SELinux is preventing /usr/sbin/bluetoothd "read" access to device rfcomm0. For complete SELinux messages. run sealert -l 8f5037b7-08d5-420f-a11e-72128f7bbf59

[root@localhost ~]# LANG=C sealert -l 8f5037b7-08d5-420f-a11e-72128f7bbf59

Summary:

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

Detailed Description:

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.

Allowing Access:

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

Additional Information:

Source Context                system_u:system_r:bluetooth_t:s0-s0:c0.c1023
Target Context                system_u:object_r:device_t:s0
Target Objects                rfcomm0 [ chr_file ]
Source                        bluetoothd
Source Path                   /usr/sbin/bluetoothd
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           bluez-4.61-1.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.10-3.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   device
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              2.6.33-0.52.rc8.git6.fc13.i686 #1 SMP Tue Feb 23
                              05:11:28 UTC 2010 i686 i686
Alert Count                   1
First Seen                    Fri Mar  5 13:51:10 2010
Last Seen                     Fri Mar  5 13:51:10 2010
Local ID                      8f5037b7-08d5-420f-a11e-72128f7bbf59
Line Numbers                  

Raw Audit Messages            

node=localhost.localdomain type=AVC msg=audit(1267786270.251:31266): avc:  denied  { read } for  pid=1928 comm="bluetoothd" name="rfcomm0" dev=devtmpfs ino=17955 scontext=system_u:system_r:bluetooth_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=localhost.localdomain type=SYSCALL msg=audit(1267786270.251:31266): arch=40000003 syscall=5 success=no exit=-13 a0=1c511e8 a1=100 a2=0 a3=1c5ed30 items=0 ppid=1 pid=1928 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)

Comment 1 Daniel Walsh 2010-03-05 14:46:04 UTC
The problem is rfcomm0 did not get labeled correctly.

matchpathcon /dev/rfcomm0
/dev/rfcomm0	system_u:object_r:tty_device_t:s0


If this device was created by udev, it would be labeled correctly.  If this device is being created by bluetooth or a bluetooth script, it needs to make sure the labelling is correct.

Comment 2 Daniel Walsh 2010-03-05 14:46:52 UTC

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


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