Description of problem: Exim MTA log file shows message for each mail delivery: 2007-10-04 11:07:06 cannot accept message: failed to stat spool directory /var/spool/exim: Permission denied Selinux audit.log ahows: ========================================================== type=AVC msg=audit(1191493092.844:2346): avc: denied { getattr } for pid=19983 comm="exim" name="/" dev=sda2 ino=2 scontext=user_u:system_r:exim_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=SYSCALL msg=audit(1191493092.844:2346): arch=c000003e syscall=137 success=no exit=-13 a0=555555612ef0 a1=7fff8f28bf70 a2=0 a3=0 items=0 ppid=25399 pid=19983 auid=500 uid=93 gid=93 euid=93 suid=93 fsuid=93 egid=93 sgid=93 fsgid=93 tty=(none) comm="exim" exe="/usr/sbin/exim" subj=user_u:system_r:exim_t:s0 key=(null) ========================================================== Running with selinux disabled, and it works fine. Version-Release number of selected component (if applicable): exim-4.66-3.fc7 selinux-policy-targeted-2.6.4-45.fc7 How reproducible: This occurs with every mail delivery. I doubt I am the only person running both Exim and SELinux, yet no-one else seems to have this problem (according to the fedora-users list). Steps to Reproduce: 1. Install both of the above packages 2. Deliver mail via the Exim MTA. 3. Actual results: Mail is not delivered, but is deferred instead on the sending MTA. Expected results: Mail should be delivered with no error messages from Exim or SELinux. Additional info: This problem has only just started, I have been running Exim and SElinux (in enforcing mode) since I first installed F7 a long time ago. Yum automatic updates are enabled. Exim, nor any directories, have changed recently. I see from the yum.log that selinux-policy has been updated twice recently: Oct 02 16:04:53 Updated: selinux-policy-targeted - 2.6.4-43.fc7.noarch Oct 04 10:38:03 Updated: selinux-policy-targeted - 2.6.4-45.fc7.noarch I receive all my mail via this F7 system, so if the problem occurred before Oct 02, then I would have noticed it sooner. Hence, the problem probably started with one of these selinux-policy-targeted updates. It was suggested on the fedora-users list that I run 'fixfiles relabel'. That didn't resolve it. I also tried 'audit2allow' and followed the man page for creating a local policy module. That didn't resolve the problem either. I tried installing the original F7 selinux-policy and targeted RPM's, but that gave some installation errors: ================================================== rpm --oldpackage --force -Uvh --nodeps selinux-policy-targeted-2.6.4-8.fc7.noarch.rpm selinux-policy-2.6.4-8.fc7.noarch.rpm Preparing... ########################################### [100%] 1:selinux-policy ########################################### [ 50%] 2:selinux-policy-targeted########################################### [100%] libsepol.print_missing_requirements: exim's global requirements were not met: type/attribute mailclient_exec_type libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! ================================================== I have now reinstalled the latest versions of both RPM's and am running with selinux disabled. John.
Forgot to add: I saw that getsebool shows two exim booleans: exim_manage_user_files --> off exim_read_user_files --> off These are off by default. I tried setting them to on, but it made no difference. John.
Fixed in selinux-policy-2.6.4-47
Sorry, but it's still not fixed. I am using: selinux-policy-2.6.4-48.fc7 selinux-policy-targeted-2.6.4-48.fc7 I have rebooted the system. If I try and telnet to port 25 on the system the audit.log shows: type=AVC msg=audit(1192539904.333:85): avc: denied { recv_msg } for saddr=141.163.177.2 src=49225 daddr=141.163.60.243 dest=25 netif=eth0 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket type=AVC msg=audit(1192539904.333:86): avc: denied { send_msg } for saddr=141.163.60.243 src=25 daddr=141.163.177.2 dest=49225 netif=eth0 scontext=system_u:system_r:exim_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket The telnet connection just times out. Similarly if I try 'telnet localhost 25', it times out. If I use 'setenforce 0' then it all works as before - email is sent/received and telnet works. John.
same here, though it's the upgrade to selinux-policy-targeted-2.6.4-48.fc7 that screwed it up for me with the port denials. I'll attach my preliminary workaround and audit log
Created attachment 233951 [details] grep fro exim through audit.log
Created attachment 233961 [details] quick fix policy addon :-P This is enough to allow me to telnet to port 25 and send an email manually. I haven't checked anything more exciting
Created attachment 234111 [details] More AVCs for exim (when called by crond)
Created attachment 234121 [details] Updated .te extras for exim under selinux-policy-targeted-2.6.4-48.fc7 More allows are needed to permit crond to send mail
Please switch bugzillas to assigned when you find them not fixed, I tend to only watch non modified bugs. Added fixes for this in Rawhide: selinux-policy-3.0.8-29.fc8.src.rpm F7: selinux-policy-2.6.4-50.fc8.src.rpm
Confirmed fixed in F8 (selinux-policy-3.0.8-53.fc8). Awaiting update in F7 to be pushed out (currently at selinux-policy-2.6.4-49.fc7).
Under F7 this is still not working. Entering into root crontab something like: * * * * * echo fred I get these messages in /var/log/messages: Nov 29 18:16:04 ash setroubleshoot: SELinux is preventing /usr/sbin/crond (system_mail_t) "entrypoint" to /usr/sbin/exim (exim_exec_t). For complete SELinux messages. run sealert -l 08408a9f-a051-40d6-8388-a5a1c9b1b679 The sealert command (above) shows: ==================================================================== Summary SELinux is preventing /usr/sbin/crond (system_mail_t) "entrypoint" to /usr/sbin/exim (exim_exec_t). Detailed Description SELinux denied access requested by /usr/sbin/crond. It is not expected that this access is required by /usr/sbin/crond 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/exim, restorecon -v /usr/sbin/exim 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 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 http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:system_mail_t:SystemLow- SystemHigh Target Context system_u:object_r:exim_exec_t Target Objects /usr/sbin/exim [ file ] Affected RPM Packages vixie-cron-4.1-84.fc7 [application]exim-4.66-3.fc7 [target] Policy RPM selinux-policy-2.6.4-57.fc7 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name ash Platform Linux ash 2.6.23.1-21.fc7 #1 SMP Thu Nov 1 21:09:24 EDT 2007 i686 athlon Alert Count 10 First Seen Thu Oct 11 11:58:01 2007 Last Seen Thu Nov 29 18:16:01 2007 Local ID 08408a9f-a051-40d6-8388-a5a1c9b1b679 Line Numbers Raw Audit Messages avc: denied { entrypoint } for comm="crond" dev=sda1 egid=0 euid=0 exe="/usr/sbin/crond" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 path="/usr/sbin/exim" pid=6629 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:exim_exec_t:s0 tty=(none) uid=0 ==================================================================== Running /restorecon -v /usr/sbin/exim' made no difference. Current SELinux RPM version: selinux-policy-2.6.4-57.fc7 John.
Fixed in selinux-policy-2.6.4-60.fc7
Bulk closing a old selinux policy bugs that were in the modified state. If the bug is still not fixed. Please reopen.