Bug 211314 - bluez: AVC denials when connecting a bluetooth mouse
bluez: AVC denials when connecting a bluetooth mouse
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bluez-utils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
: Desktop
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-18 12:43 EDT by Zack Cerza
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-28 10:52:39 EST
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 Zack Cerza 2006-10-18 12:43:46 EDT
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 12:50:52 EDT
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 13:48:05 EDT
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 15:35:14 EDT
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 15:44:31 EDT
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 15:59:14 EDT
I'm not sure what you mean by "what policy".
Comment 6 David Woodhouse 2006-10-18 16:01:10 EDT
Which SElinux policy.
grep SELINUXTYPE /etc/selinux/config
Comment 7 Zack Cerza 2006-10-18 16:07:04 EDT
SELINUXTYPE=targeted
Comment 8 Zack Cerza 2006-10-18 16:12:26 EDT
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 16:27:56 EDT
ls -lR --lcontext /var/lib/bluetooth
Comment 10 Zack Cerza 2006-10-18 17:16:11 EDT
/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 17:34:28 EDT
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 07:47:14 EDT
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 11:58:28 EDT
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 12:33:23 EDT
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 12:36:18 EDT
Just so we're clear, I didn't delete the directory, or otherwise change it.
Comment 16 David Woodhouse 2006-10-19 13:29:40 EDT
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 13:44:38 EDT
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 14:30:57 EDT
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 09:03:31 EDT
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 11:29:34 EDT
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 10:52:39 EST
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.