Bug 432230 - setroubleshoot alerts every a few seconds
setroubleshoot alerts every a few seconds
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-10 01:09 EST by Kazuyoshi Furutaka
Modified: 2008-02-18 15:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-18 15:12: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)
setroubleshoot's description of the alert (2.46 KB, text/plain)
2008-02-10 01:09 EST, Kazuyoshi Furutaka
no flags Details
an alert saved with setroubleshoot (2.44 KB, text/plain)
2008-02-13 08:55 EST, Kazuyoshi Furutaka
no flags Details

  None (edit)
Description Kazuyoshi Furutaka 2008-02-10 01:09:53 EST
Description of problem:

After installation of Fedora-9 Alpha (and update using yum), every a few seconds
setroubleshoot displays an alert.

Version-Release number of selected component (if applicable):

setroubleshoot-2.0.4-1.fc9.noarch
selinux-policy-targeted-3.2.7-1.fc9.noarch
binutils-2.18.50.0.3-1.x86_64

How reproducible:

Additional info:

attached.
Comment 1 Kazuyoshi Furutaka 2008-02-10 01:09:53 EST
Created attachment 294485 [details]
setroubleshoot's description of the alert
Comment 2 John Dennis 2008-02-11 10:53:44 EST
Looks like the loader is getting an execstack denial. Is this a known problem?
Comment 3 Daniel Walsh 2008-02-11 12:22:46 EST
What process is running as initrc_t?  Are you running some special service?

ps -eZ | grep initrc_t

execstack should not be happening.
Comment 4 Kazuyoshi Furutaka 2008-02-11 16:32:51 EST
Hi,

(In reply to comment #3)
> What process is running as initrc_t?  Are you running some special service?
> 
> ps -eZ | grep initrc_t
> 
> execstack should not be happening.

[furutaka@F9Ax8664 ~]$ ps -eZ|grep initrc_t
system_u:system_r:initrc_t:s0    1786 ?        00:04:06 vmware-guestd

Well, seems that it's caused by VMwareTools-7240-59824.i386; it's running as a
VMware guest using VMware Workstation (ver. 6.0.2 build-59824).

Yours,
Kazuyoshi
Comment 5 Daniel Walsh 2008-02-11 17:31:39 EST
What is the path to vmware-guestd
Comment 6 Kazuyoshi Furutaka 2008-02-11 17:36:48 EST
Hi,

(In reply to comment #5)
> What is the path to vmware-guestd

[furutaka@F9Ax8664 ~]$ rpm -ql VMwareTools|grep vmware-guestd
/usr/lib/vmware-tools/configurator/pam.d/vmware-guestd
/usr/lib/vmware-tools/configurator/pam.d/vmware-guestd-x64
/usr/lib/vmware-tools/sbin32/vmware-guestd
/usr/lib/vmware-tools/sbin64/vmware-guestd

Yours,
Kazuyoshi
Comment 7 Daniel Walsh 2008-02-11 17:52:34 EST
Fixed in selinux-policy-3.2.7-3.fc9
Comment 8 Kazuyoshi Furutaka 2008-02-13 08:53:37 EST
(In reply to comment #7)
> Fixed in selinux-policy-3.2.7-3.fc9

The same still occurs with the updated packages...


Comment 9 Kazuyoshi Furutaka 2008-02-13 08:55:49 EST
Created attachment 294786 [details]
an alert saved with setroubleshoot
Comment 10 Daniel Walsh 2008-02-13 09:14:41 EST
Did you restart the vmware guest?

Is it still running as initrc_t?

What does ls -lZ /usr/lib/vmware-tools/sbin32/vmware-guestd
/usr/lib/vmware-tools/sbin64/vmware-guestd

Show?

If you run restorecon -v /usr/lib/vmware-tools/sbin32/vmware-guestd
/usr/lib/vmware-tools/sbin64/vmware-guestd

Does it change the context
Comment 11 Kazuyoshi Furutaka 2008-02-13 09:29:33 EST
(In reply to comment #10)
> Did you restart the vmware guest?

Yes.  (rebooted after updating to the newer kernel, kernel-2.6.24.1-31.fc9.x86_64).

> Is it still running as initrc_t?

Yes.

$ ps -eZ|grep initrc_t
system_u:system_r:initrc_t:s0    1790 ?        00:00:16 vmware-guestd

> What does ls -lZ /usr/lib/vmware-tools/sbin32/vmware-guestd
> /usr/lib/vmware-tools/sbin64/vmware-guestd
> 
> Show?

$ ls -lZ /usr/lib/vmware-tools/sbin??/vmware-guestd
-r-xr-xr-x  root root system_u:object_r:vmware_exec_t:s0
/usr/lib/vmware-tools/sbin32/vmware-guestd
-r-xr-xr-x  root root system_u:object_r:vmware_exec_t:s0
/usr/lib/vmware-tools/sbin64/vmware-guestd

> If you run restorecon -v /usr/lib/vmware-tools/sbin32/vmware-guestd
> /usr/lib/vmware-tools/sbin64/vmware-guestd
> 
> Does it change the context

# /sbin/restorecon -v /usr/lib/vmware-tools/sbin??/vmware-guestd
# ls -lZ /usr/lib/vmware-tools/sbin??/vmware-guestd
-r-xr-xr-x  root root system_u:object_r:vmware_exec_t:s0
/usr/lib/vmware-tools/sbin32/vmware-guestd
-r-xr-xr-x  root root system_u:object_r:vmware_exec_t:s0
/usr/lib/vmware-tools/sbin64/vmware-guestd

Seems no change...
Comment 12 Kazuyoshi Furutaka 2008-02-13 09:44:59 EST
`ps -eZ|grep initrc_t` sometimes picks up other processes:
system_u:system_r:initrc_t:s0   10434 ?        00:00:00 vmware-user
system_u:system_r:initrc_t:s0   10437 ?        00:00:00 vmware-user
system_u:system_r:initrc_t:s0   10439 ?        00:00:00 vmware-user

$ ls -lZ `rpm -ql VMwareTools|grep vmware-user`
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin32/vmware-user
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin32/vmware-user-wrapper
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin32/xorg71/vmware-user
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin32/xorg71/vmware-user-wrapper
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin64/vmware-user
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin64/vmware-user-wrapper
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin64/xorg71/vmware-user
-r-xr-xr-x  root root system_u:object_r:lib_t:s0      
/usr/lib/vmware-tools/bin64/xorg71/vmware-user-wrapper

Comment 13 Daniel Walsh 2008-02-13 09:54:16 EST
Ok I guess I screwed up.

Try

# chcon -t vmware_host_exec_t /usr/lib/vmware-tools/sbin32/vmware-guestd \
/usr/lib/vmware-tools/sbin64/vmware-guestd

Then stop and restart the guests.

Does that solve the problem?
Comment 14 Kazuyoshi Furutaka 2008-02-13 10:22:50 EST
(In reply to comment #13)
> Try
> # chcon -t vmware_host_exec_t /usr/lib/vmware-tools/sbin32/vmware-guestd \
> /usr/lib/vmware-tools/sbin64/vmware-guestd
> Then stop and restart the guests.
> Does that solve the problem?

Seems NO...  After the chcon and stop/start /etc/init.d/vmware-tools (and
additional reboot), many alerts like the following are observed in
/var/log/messages:
Feb 14 00:13:02 F9Ax8664 setroubleshoot: SELinux is preventing vmware-guestd (vm
ware_host_t) "search" to ./2209 (getty_t). For complete SELinux messages. run se
alert -l e7f278ca-4c98-478b-adcd-dc6991025023
Feb 14 00:13:02 F9Ax8664 setroubleshoot: SELinux is preventing vmware-guestd (vm
ware_host_t) "search" to ./2579 (rpm_t). For complete SELinux messages. run seal
ert -l 721feb5d-776e-4a1c-9a94-2a8f54b9be83
Feb 14 00:13:03 F9Ax8664 setroubleshoot: SELinux is preventing vmware-guestd (vm
ware_host_t) "search" to ./2581 (rpm_t). For complete SELinux messages. run seal
ert -l fe327d86-207d-4e49-91b0-e9412142dc7d
Feb 14 00:13:21 F9Ax8664 setroubleshoot: SELinux is preventing vmware-guestd (vm
ware_host_t) "search" to ./2590 (unconfined_t). For complete SELinux messages. r
un sealert -l d025a38a-bb72-4c17-b64a-e8905a7aa076
Feb 14 00:13:21 F9Ax8664 setroubleshoot: SELinux is preventing vmware-guestd (vm
ware_host_t) "search" to ./2743 (gpm_t). For complete SELinux messages. run seal
ert -l e0e87dd3-ac75-4489-b959-bac0d66dcd8b
Feb 14 00:13:21 F9Ax8664 setroubleshoot: SELinux is preventing vmware-guestd (vm
ware_host_t) "search" to ./2755 (unconfined_t). For complete SELinux messages. r
un sealert -l d2790361-7bc9-40c8-9032-8280d49727a7

Furthermore, DBus seems to be dead and setroubleshoot doesn't run...

Comment 15 Kazuyoshi Furutaka 2008-02-13 10:26:23 EST
(In reply to comment #14)

Forgot the message...

> Furthermore, DBus seems to be dead and setroubleshoot doesn't run...

Feb 14 00:23:13 F9Ax8664 setroubleshoot: [dbus.ERROR] could not start dbus:
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes
include: the remote application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the network connection
was broken.
Comment 16 Kazuyoshi Furutaka 2008-02-15 20:18:42 EST
(In reply to comment #15)
... seems that it has been fixed with the latest packages including
selinux-policy-3.2.7-6.fc9, on at least a i386 system (without the treatments in
the comments 10-13).

Note You need to log in before you can comment on or make changes to this bug.