SELinux is preventing /sbin/killall5 from getattr access on the file /usr/sbin/hald. ***** Plugin catchall (100. confidence) suggests *************************** If you want to allow killall5 to have getattr access on the hald file 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 /sbin/killall5 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:hald_exec_t:s0 Target Objects /usr/sbin/hald [ file ] Source pidof Source Path /sbin/killall5 Port <Unknown> Host (removed) Source RPM Packages sysvinit-tools-2.88-1.dsf.fc15 Target RPM Packages hal-0.5.14-6.fc15 Policy RPM selinux-policy-3.9.8-4.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.36-1.fc15.i686.PAE #1 SMP Thu Oct 21 04:31:09 UTC 2010 i686 i686 Alert Count 4 First Seen Sat 13 Nov 2010 05:04:57 PM EST Last Seen Sun 14 Nov 2010 09:54:27 AM EST Local ID 04ccc881-c775-4230-accc-72648853d60e Raw Audit Messages type=AVC msg=audit(1289746467.752:58): avc: denied { getattr } for pid=1391 comm="pidof" path="/usr/sbin/hald" dev=dm-1 ino=2122399 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hald_exec_t:s0 tclass=file pidof,xdm_t,hald_exec_t,file,getattr type=SYSCALL msg=audit(1289746467.752:58): arch=i386 syscall=stat64 success=no exit=EACCES a0=bfb3047b a1=bfb2f36c a2=4d14fff4 a3=3 items=0 ppid=1388 pid=1391 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=pidof exe=/sbin/killall5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) pidof,xdm_t,hald_exec_t,file,getattr #============= xdm_t ============== allow xdm_t hald_exec_t:file getattr;
*** Bug 653111 has been marked as a duplicate of this bug. ***
*** Bug 653112 has been marked as a duplicate of this bug. ***
*** Bug 653113 has been marked as a duplicate of this bug. ***
*** Bug 653114 has been marked as a duplicate of this bug. ***
*** Bug 653115 has been marked as a duplicate of this bug. ***
*** Bug 653116 has been marked as a duplicate of this bug. ***
*** Bug 653117 has been marked as a duplicate of this bug. ***
*** Bug 653118 has been marked as a duplicate of this bug. ***
*** Bug 653119 has been marked as a duplicate of this bug. ***
*** Bug 653120 has been marked as a duplicate of this bug. ***
*** Bug 653121 has been marked as a duplicate of this bug. ***
*** Bug 653122 has been marked as a duplicate of this bug. ***
*** Bug 653123 has been marked as a duplicate of this bug. ***
*** Bug 653124 has been marked as a duplicate of this bug. ***
*** Bug 653126 has been marked as a duplicate of this bug. ***
*** Bug 653127 has been marked as a duplicate of this bug. ***
*** Bug 653128 has been marked as a duplicate of this bug. ***
*** Bug 653129 has been marked as a duplicate of this bug. ***
Were you suspending the machine from the login screen?
Also if you get a ton of avc's that look the same, please do not report them all, report one and then comment on having multiple that look the same. Otherwise we have to go through and close them as duplicates.
Locking screen after logging in. Sorry about all the multiple reports.
I get the /sbin/killall5 warnings just after logging in, without suspending.
Hi, I see these messages only when I directly log in into kde (graphical login). When I first start in text mode (3) then start kdm these messages don't appear...huh? To see when the messages happen I'll attach my /var/log/message file. Martin Kho
Created attachment 460676 [details] /var/log/message
Hi, Sorry, forgot to tell which version of selinux-policy I'm running: selinux-policy-3.9.8-6.fc15.noarch Martin Kho
kde maintainers, is kde executing hal now?
I just booted kde-x86_64-20101214.16.iso which still has this problem. hal is still on the image, pulled in by smolt and blueman.
To answer comment #26 , kde in rawhide currently no longer uses hal at all.
I booted the nightly iso to runlevel 3 and removed hal and its dependants. Then when I 'init 5' I still see similar messages mentioning killall5 and getattr access for a range of binaries (as in the duplicated bugs).
Please attach the output of ausearch -m avc
Created attachment 468973 [details] 'ausearch -m avc' for kde-x86_64-20101214.iso
Does anyone know if pidof change its behavior to stat all executable files that are currently running?
Hi, I've tried a recent desktop live build [1] and I don't get these messages. So this issue seems to be specific for kde? Martin Kho [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop-x86_64-20110124.16.iso
The GNOME spin no longer includes HAL. The KDE spin still does. So that's why you're only seeing this on the KDE spin. But there shouldn't be any HAL on the KDE spin in the first place. It's being dragged in by blueman, a non-KDE app. Why is this even on our spin? We have bluedevil already. I'm removing blueman from the KDE spin kickstart.
Actually this is a packaging issue, bluedevil doesn't Provides: dbus-bluez-pin-helper, so blueman gets dragged in.
Provides added in bluedevil-1.0.1-2.fc15, we shouldn't have HAL on the KDE spin once the build makes it through. But the underlying issue here still needs fixing, as long as HAL is still in the distro.
Hi Kevin, I'm not sure if hal and or bluedevil/man is the cause of the issue. I had bluedevil nor blueman installed - kbluetooth was still installed. Installing bluedevil-1.0.1-2 didn't made the situation any better ;-(. Sorry Martin Kho Btw when I run yum remove hal it seems no other package than "hal-storage-addon" and "hal-info" will be removed. Are there dependencies missing?
Hi again, .. and trying kde nightly build [1] - with bluedevil/-man - also gives my the killall messages when I log in. Martin Kho [1] kde-i386-20110126.16.iso
HAL is the cause of the issue. The blue* issue is only what's dragging HAL onto the nightly live images (bluedevil → bluez → blueman → hal dependency chain, the bluez → blueman item is the issue, blueman got selected as the provider for dbus-bluez-pin-helper because bluedevil was missing the Provides). On your system, HAL is present for another reason; I suppose you installed when HAL was still a dependency of many things, it should be safe to remove now.
Hi Kevin, Okay, I did remove HAL and everything seems fine. Besides, I did a little test: 1. Boot into runlevel 3 -> log in as root -> issue /usr/bin/kdm -nodaemon -> Switched to the command prompt (ctrl_alt-F2, not logging in into kde) -> the killall5 messages didn't appear in var/log/messages, huh? Attached in comment #41 you'll find the output from ps axf (boot_rnlvl3) 2. Boot into runlevel 5 -> Switched to the command prompt (ctrl-alt-F2, not logging in into kde) -> in /var/log/messages the killall5 messages appear. Attached in comment #42 you'll find again the output from ps axf (boot_rnlvl5) The big difference between the two outputs, for so far I can see, is "/usr/bin/system-setup-keyboard". It's started in runlevel 5 and not when I first boot into runlevel 3. May be this can give some clue? Martin Kho
Created attachment 475955 [details] ps axf output runlevel 3
Created attachment 475956 [details] ps axf output runlevel 5
Hi Kevin, I think there is a misunderstanding about what what you and me mean by 'issue'. Your usage of the term has to do with the dependency of blue* on HAL. Mine has to do with the killall5 selinux messages that appear in /var/log/messages and the pop up appearing after I log in into kde. Right? Martin Kho
Re: comment #40, test 1: In comment #29 I booted into runlevel 3 -> login as root -> init 5 and still saw the killall5 messages. So perhaps it is something started in runlevel 5, or perhaps kdm is started differently? I've noticed that I see more killall5 avc's after logging off and logging back on through kdm (on the livecd). So I used 'ausearch -m avc ~ wc -l' in vt2 as a crude way of testing whether the number of avc's had grown - I found that avc's are triggered when logging out of kde, or just when restarting X from kdm, but not when logging in from kdm.
I don't think that hald is the cause of the problem either. Though note that hal-libs (but not hal) is still pulled in by gnome-vfs2, iirc. This seems to be thanks to abrt-gui, system-config-* and some other system gui's, last time I checked. I think that some of the system-config-* packages are only brought in by the kde spin kickstart and aren't gnome desktop spin, but the others should be gnome's problem too.
Can you attach the AVC messages you are seeing then?
Created attachment 476626 [details] 'ausearch -m avc' after bootup and autologin for kde-x86_64-20110131.14.iso
Created attachment 476627 [details] 'ausearch -m avc -ts recent' after logout for kde-x86_64-20110131.14.iso
Created attachment 476629 [details] 'ausearch -m avc -ts recent' after restart x from kdm for kde-x86_64-20110131.14.iso
Fixed in the next version of policy, added dontaudit.
Probably a dumb question, but could this have had as similar cause to bug #669672?
Not sure how?
ioctl's with unexpected permissions? Like I said, probably a dumb question.