Bug 505397 - SELinux is preventing bluetoothd (bluetooth_t) "unlink" to sdp (var_run_t).
SELinux is preventing bluetoothd (bluetooth_t) "unlink" to sdp (var_run_t).
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-11 14:45 EDT by Bastien Nocera
Modified: 2009-09-16 10:17 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-16 10:17:44 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 Bastien Nocera 2009-06-11 14:45:11 EDT
bluez-4.37-2.fc11.x86_64

Summary:

SELinux is preventing bluetoothd (bluetooth_t) "unlink" to sdp (var_run_t).

Detailed Description:

SELinux is preventing bluetoothd (bluetooth_t) "unlink" to sdp (var_run_t). The
SELinux type var_run_t, is a generic type for all files in the directory and
very few processes (SELinux Domains) are allowed to write to this SELinux type.
This type of denial usual indicates a mislabeled file. By default a file created
in a directory has the gets the context of the parent directory, but SELinux
policy has rules about the creation of directories, that say if a process
running in one SELinux Domain (D1) creates a file in a directory with a
particular SELinux File Context (F1) the file gets a different File Context
(F2). The policy usually allows the SELinux Domain (D1) the ability to write,
unlink, and append on (F2). But if for some reason a file (sdp) was created with
the wrong context, this domain will be denied. The usual solution to this
problem is to reset the file context on the target file, restorecon -v 'sdp'. If
the file context does not change from var_run_t, then this is probably a bug in
policy. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy
package. If it does change, you can try your application again to see if it
works. The file context could have been mislabeled by editing the file or moving
the file from a different directory, if the file keeps getting mislabeled, check
the init scripts to see if they are doing something to mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v 'sdp'

Fix Command:

restorecon 'sdp'

Additional Information:

Source Context                unconfined_u:system_r:bluetooth_t:s0
Target Context                system_u:object_r:var_run_t:s0
Target Objects                sdp [ sock_file ]
Source                        bluetoothd
Source Path                   /usr/sbin/bluetoothd
Port                          <Unknown>
Host                          cookie.hadess.net
Source RPM Packages           bluez-4.37-2.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-39.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   mislabeled_file
Host Name                     cookie.hadess.net
Platform                      Linux cookie.hadess.net 2.6.29.4-167.fc11.x86_64
                              #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64
Alert Count                   1
First Seen                    Thu 11 Jun 2009 15:52:48 BST
Last Seen                     Thu 11 Jun 2009 15:52:48 BST
Local ID                      54f6ecad-1747-46df-b63b-9b856775511a
Line Numbers                  

Raw Audit Messages            

node=cookie.hadess.net type=AVC msg=audit(1244731968.471:30514): avc:  denied  { unlink } for  pid=13308 comm="bluetoothd" name="sdp" dev=sda3 ino=131345 scontext=unconfined_u:system_r:bluetooth_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file

node=cookie.hadess.net type=SYSCALL msg=audit(1244731968.471:30514): arch=c000003e syscall=87 success=no exit=-13 a0=7fffacf45bc2 a1=1 a2=0 a3=7fffacf45960 items=0 ppid=1 pid=13308 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=9 comm="bluetoothd" exe="/usr/sbin/bluetoothd" subj=unconfined_u:system_r:bluetooth_t:s0 key=(null)
Comment 1 Daniel Walsh 2009-06-11 17:46:38 EDT
restorecon /var/run/sdp

Not sure how this got created or mislabeled.

But the selinux policy is fine.


If you ran bluetooth directly, not in the init script this could have happened.
Comment 2 Bastien Nocera 2009-06-11 19:06:46 EDT
(In reply to comment #1)
> restorecon /var/run/sdp
> 
> Not sure how this got created or mislabeled.
> 
> But the selinux policy is fine.
> 
> 
> If you ran bluetooth directly, not in the init script this could have happened.  

Given that we're switching bluetoothd from being run from an initscript to being started from udev in F12, could you explain better what the problem is?
Comment 3 Daniel Walsh 2009-06-12 07:57:40 EDT
Yes we need a transition from udev to bluetooth

Fixed in selinux-policy-3.6.12-50.fc11
Comment 8 Bastien Nocera 2009-09-16 10:17:44 EDT
Fixed in Fedora 11:
https://admin.fedoraproject.org/updates/F11/FEDORA-2009-6494

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