Bug 432230
| Summary: | setroubleshoot alerts every a few seconds | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kazuyoshi Furutaka <furutaka> | ||||||
| Component: | setroubleshoot | Assignee: | Daniel Walsh <dwalsh> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | Keywords: | Reopened | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-02-18 20:12:39 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
Kazuyoshi Furutaka
2008-02-10 06:09:53 UTC
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). |