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.
Created attachment 294485 [details] setroubleshoot's description of the alert
Looks like the loader is getting an execstack denial. Is this a known problem?
What process is running as initrc_t? Are you running some special service? ps -eZ | grep initrc_t execstack should not be happening.
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
What is the path to vmware-guestd
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
Fixed in selinux-policy-3.2.7-3.fc9
(In reply to comment #7) > Fixed in selinux-policy-3.2.7-3.fc9 The same still occurs with the updated packages...
Created attachment 294786 [details] an alert saved with setroubleshoot
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
(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...
`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
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?
(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...
(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.
(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).