Bug 653108

Summary: SELinux is preventing /sbin/killall5 from getattr access on the file /usr/sbin/hald.
Product: [Fedora] Fedora Reporter: Tom <thomasbelvin>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dwalsh, jreznik, kevin, ltinkl, mgrepl, olivares14031, oliver.henshaw, rdieter, rh-bugzilla, rnovacek, ry, smparrish, than, thomasj
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:10f160aa3f2935ca23fcd238f0c877454d4acb377146ff168d2ae8932dbbfcab
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-02 19:18:19 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:
Attachments:
Description Flags
/var/log/message
none
'ausearch -m avc' for kde-x86_64-20101214.iso
none
ps axf output runlevel 3
none
ps axf output runlevel 5
none
'ausearch -m avc' after bootup and autologin for kde-x86_64-20110131.14.iso
none
'ausearch -m avc -ts recent' after logout for kde-x86_64-20110131.14.iso
none
'ausearch -m avc -ts recent' after restart x from kdm for kde-x86_64-20110131.14.iso none

Description Tom 2010-11-14 15:40:17 UTC
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;

Comment 1 Miroslav Grepl 2010-11-15 08:40:34 UTC
*** Bug 653111 has been marked as a duplicate of this bug. ***

Comment 2 Miroslav Grepl 2010-11-15 08:41:04 UTC
*** Bug 653112 has been marked as a duplicate of this bug. ***

Comment 3 Miroslav Grepl 2010-11-15 08:41:57 UTC
*** Bug 653113 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Grepl 2010-11-15 08:42:39 UTC
*** Bug 653114 has been marked as a duplicate of this bug. ***

Comment 5 Miroslav Grepl 2010-11-15 08:43:06 UTC
*** Bug 653115 has been marked as a duplicate of this bug. ***

Comment 6 Miroslav Grepl 2010-11-15 08:43:32 UTC
*** Bug 653116 has been marked as a duplicate of this bug. ***

Comment 7 Miroslav Grepl 2010-11-15 08:43:58 UTC
*** Bug 653117 has been marked as a duplicate of this bug. ***

Comment 8 Miroslav Grepl 2010-11-15 08:44:23 UTC
*** Bug 653118 has been marked as a duplicate of this bug. ***

Comment 9 Miroslav Grepl 2010-11-15 08:44:46 UTC
*** Bug 653119 has been marked as a duplicate of this bug. ***

Comment 10 Miroslav Grepl 2010-11-15 08:45:11 UTC
*** Bug 653120 has been marked as a duplicate of this bug. ***

Comment 11 Miroslav Grepl 2010-11-15 08:45:38 UTC
*** Bug 653121 has been marked as a duplicate of this bug. ***

Comment 12 Miroslav Grepl 2010-11-15 08:46:02 UTC
*** Bug 653122 has been marked as a duplicate of this bug. ***

Comment 13 Miroslav Grepl 2010-11-15 08:46:44 UTC
*** Bug 653123 has been marked as a duplicate of this bug. ***

Comment 14 Miroslav Grepl 2010-11-15 08:49:03 UTC
*** Bug 653124 has been marked as a duplicate of this bug. ***

Comment 15 Miroslav Grepl 2010-11-15 08:49:31 UTC
*** Bug 653126 has been marked as a duplicate of this bug. ***

Comment 16 Miroslav Grepl 2010-11-15 08:50:39 UTC
*** Bug 653127 has been marked as a duplicate of this bug. ***

Comment 17 Miroslav Grepl 2010-11-15 08:51:03 UTC
*** Bug 653128 has been marked as a duplicate of this bug. ***

Comment 18 Miroslav Grepl 2010-11-15 08:51:28 UTC
*** Bug 653129 has been marked as a duplicate of this bug. ***

Comment 19 Daniel Walsh 2010-11-15 15:59:07 UTC
Were you suspending the machine from the login screen?

Comment 20 Daniel Walsh 2010-11-15 16:02:59 UTC
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.

Comment 21 Tom 2010-11-15 18:08:12 UTC
Locking screen after logging in.
Sorry about all the multiple reports.

Comment 22 Tom 2010-11-15 21:33:15 UTC
I get the /sbin/killall5 warnings just after logging in, without suspending.

Comment 23 Martin Kho 2010-11-15 21:41:12 UTC
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

Comment 24 Martin Kho 2010-11-15 21:43:13 UTC
Created attachment 460676 [details]
/var/log/message

Comment 25 Martin Kho 2010-11-15 21:46:22 UTC
Hi,

Sorry, forgot to tell which version of selinux-policy I'm running:

selinux-policy-3.9.8-6.fc15.noarch

Martin Kho

Comment 26 Daniel Walsh 2010-11-16 16:58:03 UTC
kde maintainers, is kde executing hal now?

Comment 27 Oliver Henshaw 2010-12-15 18:29:23 UTC
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.

Comment 28 Rex Dieter 2010-12-15 18:39:38 UTC
To answer comment #26 , kde in rawhide currently no longer uses hal at all.

Comment 29 Oliver Henshaw 2010-12-15 20:00:55 UTC
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).

Comment 30 Daniel Walsh 2010-12-15 20:18:31 UTC
Please attach the output of ausearch -m avc

Comment 31 Oliver Henshaw 2010-12-15 21:23:50 UTC
Created attachment 468973 [details]
'ausearch -m avc' for kde-x86_64-20101214.iso

Comment 32 Daniel Walsh 2010-12-15 21:46:24 UTC
Does anyone know if pidof change its behavior to stat all executable files that are currently running?

Comment 33 Martin Kho 2011-01-29 10:14:13 UTC
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

Comment 34 Kevin Kofler 2011-01-29 15:06:10 UTC
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.

Comment 35 Kevin Kofler 2011-01-29 15:15:40 UTC
Actually this is a packaging issue, bluedevil doesn't
Provides: dbus-bluez-pin-helper, so blueman gets dragged in.

Comment 36 Kevin Kofler 2011-01-29 15:27:41 UTC
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.

Comment 37 Martin Kho 2011-01-29 15:54:41 UTC
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?

Comment 38 Martin Kho 2011-01-29 16:11:49 UTC
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

Comment 39 Kevin Kofler 2011-01-29 16:24:13 UTC
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.

Comment 40 Martin Kho 2011-01-29 17:14:18 UTC
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

Comment 41 Martin Kho 2011-01-29 17:15:06 UTC
Created attachment 475955 [details]
ps axf output runlevel 3

Comment 42 Martin Kho 2011-01-29 17:15:33 UTC
Created attachment 475956 [details]
ps axf output runlevel 5

Comment 43 Martin Kho 2011-01-29 17:51:30 UTC
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

Comment 44 Oliver Henshaw 2011-01-29 17:54:00 UTC
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.

Comment 45 Oliver Henshaw 2011-01-29 18:05:32 UTC
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.

Comment 46 Daniel Walsh 2011-02-01 22:50:10 UTC
Can you attach the AVC messages you are seeing then?

Comment 47 Oliver Henshaw 2011-02-02 18:23:51 UTC
Created attachment 476626 [details]
'ausearch -m avc' after bootup and autologin for kde-x86_64-20110131.14.iso

Comment 48 Oliver Henshaw 2011-02-02 18:24:49 UTC
Created attachment 476627 [details]
'ausearch -m avc -ts recent' after logout for kde-x86_64-20110131.14.iso

Comment 49 Oliver Henshaw 2011-02-02 18:25:38 UTC
Created attachment 476629 [details]
'ausearch -m avc -ts recent' after restart x from kdm for kde-x86_64-20110131.14.iso

Comment 50 Daniel Walsh 2011-02-02 19:18:19 UTC
Fixed in the next version of policy, added dontaudit.

Comment 51 Oliver Henshaw 2011-03-06 17:22:43 UTC
Probably a dumb question, but could this have had as similar cause to bug #669672?

Comment 52 Daniel Walsh 2011-03-07 22:17:03 UTC
Not sure how?

Comment 53 Oliver Henshaw 2011-03-08 10:36:22 UTC
ioctl's with unexpected permissions? Like I said, probably a dumb question.