Bug 204655

Summary: Wrong SELinux context prevents hidd from working
Product: [Fedora] Fedora Reporter: Radek Bíba <rbiba>
Component: bluez-utilsAssignee: David Woodhouse <dwmw2>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: dwalsh, paul.moore, sdsmall
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-03 21:13:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150224, 208901    
Attachments:
Description Flags
Potential fix. none

Description Radek Bíba 2006-08-30 16:57:21 UTC
Description of problem:
SSIA

Version-Release number of selected component (if applicable):
bluez-utils-2.25-4

How reproducible:
Always

Steps to Reproduce:
1. service hidd start
2. select Remote Desktop from your phone menu
  
Actual results:
Aug 30 18:43:40 stinker hcid[3389]: link_key_request (sba=SNIP, dba=SNIP)
Aug 30 18:43:40 stinker hidd[3783]: HID create error 13 (Permission denied)
Aug 30 18:43:40 stinker kernel: audit(1156956220.482:29): avc:  denied  { read }
for  pid=3783 comm="hidd" name="hidd" dev=sda1 ino=4300071
scontext=user_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file

Expected results:
guess what :)
it works great after setenforce 0 (kernel: input: Bluetooth HID Boot Protocol
Device as /class/input/input4)

Comment 1 Radek Bíba 2006-09-07 09:14:27 UTC
BTW, audit2allow saye:
allow bluetooth_t var_lib_t:file read;

Comment 2 Daniel Walsh 2006-09-07 12:39:51 UTC
Do you know which file/directory this is?  Which bluetooth rpms do you have
installed?

Comment 3 Radek Bíba 2006-09-07 12:49:34 UTC
$ ls -dZ /var/lib/bluetooth/
drwxr-xr-x  root root user_u:object_r:var_lib_t        /var/lib/bluetooth/

$ rpm -qa | grep ^bluez
bluez-libs-2.25-1
bluez-utils-2.25-4
bluez-pin-0.30-2

HTH

Comment 4 Daniel Walsh 2006-09-18 19:21:09 UTC
Fixed in selinux-policy-2.3.14-3

Comment 5 David Woodhouse 2006-09-29 07:24:01 UTC
That's not sufficient, at least in rawhide. Now we get...

accept(4, {sa_family=AF_BLUETOOTH,
sa_data="\21\0\27~\300\224\n\0\0m\221\251\177\355"}, [10]) = 7
getsockname(7, 0x7fed8ff6, [10])        = -1 EACCES (Permission denied)


audit(1159480772.521:12): avc:  denied  { getattr } for  pid=1804 comm="hidd"
scontext=system_u:system_r:bluetooth_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket

Comment 6 David Woodhouse 2006-09-29 08:37:03 UTC
I also see this (with setenforce 0):

audit(1159518792.004:35): avc:  denied  { write } for  pid=5852
comm="khidpd_00000000" scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket


Comment 7 James Morris 2006-09-29 16:34:03 UTC
(In reply to comment #5)
> That's not sufficient, at least in rawhide. Now we get...
> 
> accept(4, {sa_family=AF_BLUETOOTH,
> sa_data="\21\0\27~\300\224\n\0\0m\221\251\177\355"}, [10]) = 7
> getsockname(7, 0x7fed8ff6, [10])        = -1 EACCES (Permission denied)
> 
> 
> audit(1159480772.521:12): avc:  denied  { getattr } for  pid=1804 comm="hidd"
> scontext=system_u:system_r:bluetooth_t:s0
> tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket

Userland sockets should never end up unlabled.  Can you post a full strace -f of
the program from start?


Comment 8 Stephen Smalley 2006-09-29 16:38:32 UTC
Suspect selinux_sock_graft is erroneously replacing the isec->sid of accepted
sockets that are not INET and thus never get their sksec->sid set up properly.

Comment 9 Stephen Smalley 2006-09-29 16:45:29 UTC
Actually, INET | INET6 | LOCAL should be ok I believe, but other families
wouldn't have the necessary hooks to set up the sksec SID.


Comment 10 David Woodhouse 2006-09-29 18:27:12 UTC
Created attachment 137414 [details]
Potential fix.

This makes it work, but could do with vetting by someone who actually
understands the code in question.