-rwxr-sr-x root smmsp system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail --- Summary: SELinux is preventing execute_command (spacewalk_monitoring_t) "getattr" to /usr/sbin/sendmail.sendmail (sendmail_exec_t). Detailed Description: SELinux denied access requested by execute_command. It is not expected that this access is required by execute_command and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /usr/sbin/sendmail.sendmail, restorecon -v '/usr/sbin/sendmail.sendmail' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context user_u:system_r:spacewalk_monitoring_t Target Context system_u:object_r:sendmail_exec_t Target Objects /usr/sbin/sendmail.sendmail [ file ] Source gogo.pl Source Path /usr/bin/perl Port <Unknown> Host id-sws-prd-01.ethz.ch Source RPM Packages perl-5.8.8-27.el5 Target RPM Packages sendmail-8.13.8-2.el5 Policy RPM selinux-policy-2.4.6-255.el5_4.4 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name id-sws-prd-01.ethz.ch Platform Linux id-sws-prd-01.ethz.ch 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64 Alert Count 4092 First Seen Thu Apr 29 23:13:24 2010 Last Seen Tue May 4 22:07:20 2010 Local ID 9c31621b-1307-4a5e-9c4e-16a82912d935 Line Numbers Raw Audit Messages host=id-sws-prd-01.ethz.ch type=AVC msg=audit(1273003640.434:19764): avc: denied { getattr } for pid=12971 comm="execute_command" path="/usr/sbin/sendmail.sendmail" dev=dm-0 ino=984784 scontext=user_u:system_r:spacewalk_monitoring_t:s0 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file host=id-sws-prd-01.ethz.ch type=SYSCALL msg=audit(1273003640.434:19764): arch=c000003e syscall=4 success=no exit=-13 a0=42cc2b0 a1=3f01140 a2=3f01140 a3=0 items=0 ppid=12968 pid=12971 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1678 comm="execute_command" exe="/usr/bin/perl" subj=user_u:system_r:spacewalk_monitoring_t:s0 key=(null)
Reassigning to our selinux guru.
I'd need to know what exactly you / the Spacewalk server has been doing when you got this AVC denial. Please, always use the general bugzilla template, ideally with steps to reproduce. We need to investigate why the monitoring system thought that it would be good idea to run /usr/sbin/sendmail.sendmail in the first place, and for that we need the full reports.
I didn't add more because that's all I had investigated so far - basically I missed to mention that we have lots of those messages and not only one single occurence. Here comes the template. Description of problem: Having a closer look upon it now I see that this seems to occur every 5 minutes. Since that Spacewalk only has 4 systems subscribed to and only one is being monitored I can see that the only probe that is configured has an interval of 5 minutes. So I guess that with every check it wants to send a mail. For the past days rhnmd has not been running (because of another selinux problem which I'm going to report) on the target system and I thought that might be the reason. But I started rhnmd again in the meantime and there's still selinux reports. Version-Release number of selected component (if applicable): spacewalk-monitoring-1.0.1-1.el5 spacewalk-monitoring-selinux-1.0.1-1.el5 How reproducible: Unknown, only have one spacewalk instance at hand but it still occurs there. Steps to Reproduce: 1. create a monitoring probe 2. push scout config Actual results: - SELinux is preventing execute_command (spacewalk_monitoring_t) "getattr" to /usr/sbin/sendmail.sendmail (sendmail_exec_t). - probe works, system is healthy Expected results: - no SELinux denial - probe works Additional info: I really don't know why monitoring is trying to send an email at all or where to. There's at least no notification methods defined (and therefore none specified in the monitoring probe).
(In reply to comment #3) > Steps to Reproduce: > 1. create a monitoring probe What probe is that, exactly?
Created attachment 411546 [details] Screenshot of monitoring probe
See the new attachement above for the probe with all the details. As you can see I changed the interval to 1 minute but the denial still only occurs every 5 minutes. Also, since I started rhnmd on the client/target system a bit over one hour ago there's lots of additional SELinux messages. I'll attach messages and audit.log next so you can be sure I don't miss to mention anything of importance.
Created attachment 411549 [details] Spacewalk syslog
Created attachment 411550 [details] Spacewalk audit.log
Oh, I forgot to mention that at May 5 12:2* I did a rhn-satellite restart, that's why there's some JVM messages in there. The restart was necessary as I changed the SSL certificates of httpd and jabberd (after they have been signed).
*** Bug 636356 has been marked as a duplicate of this bug. ***
Mass-moving to space13.
The fix for this already fixed in same patch for https://bugzilla.redhat.com/show_bug.cgi?id=677680 See https://bugzilla.redhat.com/show_bug.cgi?id=677680 Cheers, Marcelo Moreira de Mello
Moving to space16.
(In reply to comment #12) > The fix for this already fixed in same patch for > https://bugzilla.redhat.com/show_bug.cgi?id=677680 > > > See https://bugzilla.redhat.com/show_bug.cgi?id=677680 > > Cheers, > Marcelo Moreira de Mello Nack that patch.
Fixed in Spacewalk master, afd9db44bbae4e9abda70a4ec1fecea7c0dab69b. Tagged as spacewalk-monitoring-selinux-1.6.2-1.
Spacewalk 1.6 has been released.