abrt version: 2.0.5.980 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 3.1.0-0.rc6.git0.3.fc16.x86_64 reason: SELinux is preventing khidpd_045e0762 from 'write' accesses on the socket Unknown. time: Tue Sep 27 11:02:39 2011 description: :SELinux is preventing khidpd_045e0762 from 'write' accesses on the socket Unknown. : :***** Plugin catchall (100. confidence) suggests *************************** : :If you believe that khidpd_045e0762 should be allowed write access on the Unknown socket by default. :Then you should report this as a bug. :You can generate a local policy module to allow this access. :Do :allow this access for now by executing: :# grep khidpd_045e0762 /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:kernel_t:s0 :Target Context system_u:object_r:unlabeled_t:s0 :Target Objects Unknown [ socket ] :Source khidpd_045e0762 :Source Path khidpd_045e0762 :Port <Unknown> :Host (removed) :Source RPM Packages :Target RPM Packages :Policy RPM selinux-policy-3.10.0-32.fc16 :Selinux Enabled True :Policy Type targeted :Enforcing Mode Permissive :Host Name (removed) :Platform Linux orwell.ignore-your.tv : 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP Fri Sep 16 : 12:26:22 UTC 2011 x86_64 x86_64 :Alert Count 1 :First Seen Tue 27 Sep 2011 10:46:18 AM CDT :Last Seen Tue 27 Sep 2011 10:46:18 AM CDT :Local ID 4934d789-6555-45ab-b51a-f1cf64a1ea22 : :Raw Audit Messages :type=AVC msg=audit(1317138378.811:257): avc: denied { write } for pid=15274 comm="khidpd_045e0762" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=socket : : :Hash: khidpd_045e0762,kernel_t,unlabeled_t,socket,write : :audit2allow : :#============= kernel_t ============== :allow kernel_t unlabeled_t:socket write; : :audit2allow -R : :#============= kernel_t ============== :allow kernel_t unlabeled_t:socket write; :
This should not happen.
is this reproducible? definitely something broken in the kernel when we have an unlabeled socket...
That is interesting ... looks like somehow a socket is being created without a label. Any way to reproduce this on a regular basis?
Yes, I get about a dozen of these a day on my Thinkpad T420.
(In reply to comment #4) > Yes, I get about a dozen of these a day on my Thinkpad T420. Can you associate it with any thing specific that you are doing?
It immediately follows logs of a bluetooth keyboard waking up (I'm running in enforcing=0), from /var/log/messages: Sep 28 12:31:09 orwell kernel: [ 9024.105307] input: Microsoft Bluetooth Mobile Keyboard 6000 as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0: 11/input12 Sep 28 12:31:09 orwell kernel: [ 9024.105885] generic-bluetooth 0005:045E:0762.0004: input,hidraw1: BLUETOOTH HID v0.13 Keyboard [Microsoft Bluetooth Mobile Keyboard 6000] on 88:9F:FA:EA:DC:01 Sep 28 12:31:09 orwell dbus-daemon[1209]: dbus[1209]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Sep 28 12:31:09 orwell dbus[1209]: [system] Activating service name='org.fedoraproject.Setroubleshootd' (using servicehelper) Sep 28 12:31:10 orwell dbus[1209]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Sep 28 12:31:10 orwell dbus-daemon[1209]: dbus[1209]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Sep 28 12:31:11 orwell setroubleshoot: SELinux is preventing khidpd_045e0762 from write access on the socket Unknown. For complete SELinux messages. run sealert -l 3ab6cfcd-43 a9-4694-85e8-7ccae157abfc Sep 28 12:31:11 orwell setroubleshoot: SELinux is preventing /usr/sbin/acpid from read access on the chr_file event10. For complete SELinux messages. run sealert -l 3e506bd8-c 575-44ce-b59f-ff93ba2cf10b Sep 28 12:31:11 orwell setroubleshoot: SELinux is preventing /usr/sbin/acpid from read access on the chr_file event10. For complete SELinux messages. run sealert -l 3e506bd8-c 575-44ce-b59f-ff93ba2cf10b Sep 28 12:31:11 orwell setroubleshoot: SELinux is preventing /usr/sbin/acpid from ioctl access on the chr_file /dev/input/event10. For complete SELinux messages. run sealert -l a4cc1323-a7a9-4c2e-94c9-bccb425c408e
If I had to pick a victom I would guess bluetooth. He is also seeing a device labeling race condition with the /dev/input/event10 being mislabeled for a second before udev fixes this. This will disappear in F16....
(In reply to comment #7) > If I had to pick a victom I would guess bluetooth. He is also seeing a device > labeling race condition with the /dev/input/event10 being mislabeled for a > second before udev fixes this. This will disappear in F16.... So is this another udev labeling problem? Why will it disappear in F16?
Just FYI, I'm running F16 alpha+updates now :-)
the device file labeling will be fixed because of the addition of the filename transition rules, so when the device file is created by devtmpfs it will automatically get the right label, instead of only being relabeled after it is created by udev. the unlabeled socket is the real bug here....
(In reply to comment #10) > the unlabeled socket is the real bug here.... Agreed. Anybody here a bluetooth expert? I need to find out where this socket is being created in the first place ... my guess is some kernel code path that isn't creating a socket via __sock_create().
James Cape, sadly we were only going up to event9 in that version now we go all the way to 19. Which should handle most cases. Paul the race condition that we have prior to F16 is that devices in devtmpfs get created by the kernel with the default label device_t. Udev is in charge of fixing the label, if a confined process touches the device before udev has fixed the label, we get this crappy AVC messages. In F16 as Eric has stated we have added filename transition rules that will allow the kernel to create most of the devices with the correct label. sesearch -T -s kernel_t -t device_t | wc 1417 9904 97394
Thanks for the clarification. I've been taking a quick look at net/bluetooth and there is definitely some questionable sock creation going on in there ... need to dig a bit more on this before I'm sure, but I suspect some bluetooth cleanup/fixing is needed. James, I don't have any bluetooth devices to use in helping diagnose/test this issue; if I provided some patches would you be able to help run some tests?
As long as it's a package, yes (I'd prefer not to build a kernel if I don't have to :-)).
(In reply to comment #14) > As long as it's a package, yes (I'd prefer not to build a kernel if I don't > have to :-)). No problem, thanks for your help on this. I'll update the BZ when I have something for you to test; although it may not be for a day or two as I want to spend some more time looking at this first.
Great, thanks.
I believe I've found the problem and I've got a patch that doesn't appear to cause any major regressions after a few simple tests on my system; the downside is that I'm not actually able to test any of the bluetooth functionality. I'm going to attach the patch to this bugzilla and as soon as I have a place to host the kernel test RPM I'll update this entry for others to test and validate the bluetooth bits. Hopefully, I should have a place to post the kernel RPM within a day or two.
Created attachment 526518 [details] Bluetooth LSM/socket patch
http://people.redhat.com/~eparis/bz741703/ Should contain a link to paul's kernel in question.
Hi James, Any updates?
Just started testing now, will followup later today.
So far so good, but X11 is running extremely slow compared to previously, so I'm not sure if it's related or not...
Thanks for the feedback, I'm glad the patch fixed the bluetooth problem. As far as X is concerned, have you updated any other parts of your system that might affect X? If nothing else, the kernel package I built with the patch (and Eric so graciously hosted) is a newer version that what you were running previously so that might have some effect. Not to mention the bumps in the road that come along with running Rawhide :) I'm going to go ahead and start pushing this patch upstream, it is really limited to just the bluetooth stack so I'd be very surprised if it affected X - however, you _never_ want to rule anything out completely. If you notice anything else odd, please let me know.
Patch posted upstream: * http://www.spinics.net/lists/netdev/msg176425.html
*** Bug 654206 has been marked as a duplicate of this bug. ***
*** Bug 679128 has been marked as a duplicate of this bug. ***
*** Bug 698101 has been marked as a duplicate of this bug. ***
The patch was accepted upstream by David Miller on October 18th, closing this bug as the fix is now upstream and should trickle down to Fedora.
*** Bug 748501 has been marked as a duplicate of this bug. ***
*** Bug 746514 has been marked as a duplicate of this bug. ***