Bug 211314 - bluez: AVC denials when connecting a bluetooth mouse
Summary: bluez: AVC denials when connecting a bluetooth mouse
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez-utils   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Woodhouse
QA Contact:
URL:
Whiteboard:
Keywords: Desktop
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-18 16:43 UTC by Zack Cerza
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-28 15:52:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Zack Cerza 2006-10-18 16:43:46 UTC
Description of problem:
During the process of connecting a bluetooth mouse, I issued commands like:

hcitool scan
hcitool inq
sdptool browse
hidd --connect
service bluetooth restart

and noticed later that selinux had been denying certain things:

avc: denied { read } for comm='"hidd"' dev='dm-0' egid='0' euid='0'
exe='"/usr/bin/hidd"' exit='9' fsgid='0' fsuid='0' gid='0' items='0'
name='"hidd"' pid='7243' scontext=system_u:system_r:bluetooth_t:s0 sgid='0'
subj='system_u:system_r:bluetooth_t:s0' suid='0' tclass='file'
tcontext=user_u:object_r:var_lib_t:s0 tty='(none)' uid='0' 

avc: denied { getattr } for comm='"hidd"' dev='dm-0' egid='0' euid='0'
exe='"/usr/bin/hidd"' exit='0' fsgid='0' fsuid='0' gid='0' items='0'
name='"hidd"' path='"/var/lib/bluetooth/00:0E:9B:D9:57:99/hidd"' pid='7243'
scontext=system_u:system_r:bluetooth_t:s0 sgid='0'
subj='system_u:system_r:bluetooth_t:s0' suid='0' tclass='file'
tcontext=user_u:object_r:var_lib_t:s0 tty='(none)' uid='0' 

avc: denied { lock } for comm='"hidd"' dev='dm-0' egid='0' euid='0'
exe='"/usr/bin/hidd"' exit='0' fsgid='0' fsuid='0' gid='0' items='0'
name='"hidd"' path='"/var/lib/bluetooth/00:0E:9B:D9:57:99/hidd"' pid='7243'
scontext=system_u:system_r:bluetooth_t:s0 sgid='0'
subj='system_u:system_r:bluetooth_t:s0' suid='0' tclass='file'
tcontext=user_u:object_r:var_lib_t:s0 tty='(none)' uid='0' 

Oddly enough, I was able to get the mouse working before I even noticed these
denials. Maybe hidd really doesn't need to do these things?


Version-Release number of selected component (if applicable):
bluez-utils-2.25-12
selinux-policy-targeted-2.3.18-10

Comment 1 David Woodhouse 2006-10-18 16:50:52 UTC
Please use the bluez packages from http://david.woodhou.se/bluez/ and tell me if
you can reproduce this.

Comment 2 Zack Cerza 2006-10-18 17:48:05 UTC
I haven't been able to, so far. What's different with those packages? I see
bt-applet, which mainly just lets me toggle discoverability.

Comment 3 Zack Cerza 2006-10-18 19:35:14 UTC
Just got these:

type=AVC msg=audit(1161199971.918:240): avc:  denied  { read } for  pid=7243
comm="hidd" name="hidd" dev=dm-0 ino=1497973
scontext=system_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file
type=AVC msg=audit(1161199971.918:241): avc:  denied  { lock } for  pid=7243
comm="hidd" name="hidd" dev=dm-0 ino=1497973
scontext=system_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file
type=AVC msg=audit(1161199971.918:242): avc:  denied  { getattr } for  pid=7243
comm="hidd" name="hidd" dev=dm-0 ino=1497973
scontext=system_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file


Comment 4 David Woodhouse 2006-10-18 19:44:31 UTC
What policy are you using? I'm using the above-referenced bluez-utils-3.7-2
package in a clean install of FC6 and a bluetooth mouse works fine.

Comment 5 Zack Cerza 2006-10-18 19:59:14 UTC
I'm not sure what you mean by "what policy".

Comment 6 David Woodhouse 2006-10-18 20:01:10 UTC
Which SElinux policy.
grep SELINUXTYPE /etc/selinux/config

Comment 7 Zack Cerza 2006-10-18 20:07:04 UTC
SELINUXTYPE=targeted


Comment 8 Zack Cerza 2006-10-18 20:12:26 UTC
Just realized I was in Permissive mode.

Oct 18 16:10:48 tak setroubleshoot:      SELinux is preventing /usr/bin/hidd
(bluetooth_t) "read" access to hidd (var_lib_t).      See audit.log for complete
SELinux messages. id = <xxx>
Oct 18 16:10:50 tak last message repeated 9 times
Oct 18 16:10:55 tak hidd[7243]: HID create error 13 (Permission denied)
Oct 18 16:10:58 tak setroubleshoot:      SELinux is preventing /usr/bin/hidd
(bluetooth_t) "read" access to hidd (var_lib_t).      See audit.log for complete
SELinux messages. id = <xxx>

Mouse doesn't work if set to Enforcing.


Comment 9 David Woodhouse 2006-10-18 20:27:56 UTC
ls -lR --lcontext /var/lib/bluetooth

Comment 10 Zack Cerza 2006-10-18 21:16:11 UTC
/var/lib/bluetooth:
total 8
drwxr-xr-x 2 system_u:object_r:var_lib_t      root root 4096 Oct 18 13:44
00:0E:9B:D9:57:99

/var/lib/bluetooth/<xxx>:
total 64
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  54 Oct 18 16:38 classes
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  17 Oct 18 13:46 config
-rw-r--r-- 1 system_u:object_r:bluetooth_var_lib_t root root  70 Oct 18 16:38
features
-rw-r--r-- 1 user_u:object_r:var_lib_t        root root 243 Oct 18 13:46 hidd
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  42 Oct 18 13:43 lastseen
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  42 Oct 18 16:38 lastused
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  28 Oct 18 13:44
manufacturers
-rw-r--r-- 1 system_u:object_r:bluetooth_var_lib_t root root 222 Oct 18 16:38 names


Comment 11 David Woodhouse 2006-10-18 21:34:28 UTC
Ok, so /var/lib/bluetooth/00:0E:9B:D9:57:99/hidd managed to get created with the
wrong context. Remove it and re-pair with the device (or briefly run hidd with
the  -Z option while letting it reconnect. It _should_ get created with the
correct context.

I think I have to defer to selinux folks now; I'm getting out of my depth
because I don't quite understand where the labels are derived from when files
are created.



Comment 12 Daniel Walsh 2006-10-19 11:47:14 UTC
The problem is the /var/lib/bluetooth directory was created with wrong context.
It should be bluetooth_var_lib_t.  Did this directory get created after the rpm
install?  RPM should have set the correct context on the directory.

restorecon -R -v /var/lib/bluetooth

should fix.

Comment 13 Zack Cerza 2006-10-19 15:58:28 UTC
I don't know when /var/lib/bluetooth was created. Possibly in an older version
of the package. If restorecon can fix this problem, why isn't it being run in a
%post or something? This isn't something the user should have to do.

Comment 14 Daniel Walsh 2006-10-19 16:33:23 UTC
This is not somethine we are seeing, if the user deletes and recreates the
directory and it has the wrong permissions on it, there is nothing we can do
other than tell them how to correct the permissions, which is basically what
this error is.  If you delete the directory and recreate it then this could
happen, also if they ran deleted the directory and ran the hidd by hand it could
happen if hidd creates the directory.  I am updating policy to allow this to be
created with the correct context.

Comment 15 Zack Cerza 2006-10-19 16:36:18 UTC
Just so we're clear, I didn't delete the directory, or otherwise change it.

Comment 16 David Woodhouse 2006-10-19 17:29:40 UTC
The bluez-utils package owns this directory -- it should have been created when
the package was installed, and I believe it's supposed to magically get the
right label somehow, whether that's during the install or by manually installing
it with yum or rpm later.

Was this a clean install of rawhide? An upgrade? Had selinux ever been disabled?
Was bluez-utils installed from the beginning or was it updated later?

Comment 17 Daniel Walsh 2006-10-19 17:44:38 UTC
There also could have been a policy update where the label was changed, and for
some reason this directory did not get labeled correctly.  So I think we can
cloase this bug for now and reopen it if it reappears.

Comment 18 Zack Cerza 2006-10-19 18:30:57 UTC
This was originally an FC5 install that I updated to rawhide a few weeks ago.
selinux was never disabled, but it did spend a lot of time in permissive mode.
bluez-utils was installed at the very beginning, with FC5.

I'm not really comfortable with closing this bug, as it makes hardware that
should work... not work. There should be a way to ensure that labels are
correct, no?

Comment 19 Daniel Walsh 2006-10-20 13:03:31 UTC
Yes you can relabel the entire system.

# touch /.autorelabel
# reboot

You can also check the labeles on the system 

# fixfiles check

rpm -V should show you a problem,  but bugs on updates to happen, and something
happened on a rawhide update to set this label incorrectly or not correct the
label (more likely). 

This is similar to if the Ownership or mode on the file was wrong.  There is
limited ways to 


Comment 20 Zack Cerza 2006-10-20 15:29:34 UTC
It looks like the end of your comment was cut off.

I've seen the /.autorelabel workaround suggested before, for different issues.
Why don't we ship with /.autorelabel? I'm looking for a solution that doesn't
require a customer to make support calls, and eventually escalate to IT.

I ran 'fixfiles check', and here was the relevant output:
/sbin/restorecon reset /var/lib/bluetooth/00:0E:9B:D9:57:99 context
system_u:object_r:var_lib_t:s0->system_u:object_r:bluetooth_var_lib_t:s0
/sbin/restorecon reset /var/lib/bluetooth/00:0E:9B:D9:57:99/hidd context
user_u:object_r:var_lib_t:s0->system_u:object_r:bluetooth_var_lib_t:s0

Notice how /var/lib/bluetooth/ isn't mentioned; just the subdirectory.

# rpm -V bluez-utils; echo $?
0

Comment 21 Daniel Walsh 2006-11-28 15:52:39 UTC
On an upgrade install I believe /.autorelabel is going to be turned on for
RHEL5.  But for this update it was not.

The update scripts attempt to fix the context, but sometimes they miss.

restorecon -R -v /var/lib/bluetooth would have fixed the problem also without
the full autorelabel


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