Description of problem: Sendmail can not open mimedefang socket file. Oct 28 12:47:28 orange sendmail[2009]: o9SJlSt2002009: Milter: initialization failed, temp failing commands Oct 28 12:48:01 orange sendmail[2012]: o9SJm1uj002012: Milter (mimedefang): error connecting to filter: Permission denied Oct 28 12:48:01 orange sendmail[2012]: o9SJm1uj002012: Milter (mimedefang): to error state Version-Release number of selected component (if applicable): mimedefang-2.71-1.fc13.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure sendmail to use mimedefang 2. Start up sendmail and mimedefang 3. Get above errors from sendmail when messages are sent Actual results: No messages get delivered Expected results: Messages should get processed and either delivered or rejected Solution: chcon -t spamd_exec_t /usr/bin/mimedefang Additional info: In the audit logs selinux is blocking sendmail form connecting to the mimedefang socket. This is because /usr/bin/mimedefang on install is configured with wrong selinux context type
Daniel, may you please take care of this? Thank you.
If this works, then it is fine with me.
I'm not sure, whether only "spamd_exec_t" is the real solution. Hasn't MIMEDefang an own policy? Because the MIMEDefang socket might be used by Postfix as well and it might be used be others, too. MIMEDefang is more than just a SpamAssassin connector...
After a quick look I am thinking about adding mimedefang to the milters. I am going to do some tests.
Created attachment 456903 [details] mimedefang patch Dan, mimedefang is treated as spamd policy, but I believe the attached patch is better solution for mimedefang. I am planning to do a scratch build for F13 first and people can test it.
The selinux-policy and selinux-policy-targeted packages are available from koji http://koji.fedoraproject.org/koji/taskinfo?taskID=2569109 Matthew, could you test it?
Installed rpm -Fvh selinux-policy-3.7.19-70.fc13.noarch.rpm selinux-policy-targeted-3.7.19-70.fc13.noarch.rpm Now getting the following error: Nov 1 13:00:40 orange mimedefang[27377]: oA1K0eEf027417: Could not create directory /var/spool/MIMEDefang/mdefang-oA1K0eEf027417: Permission denied Messages all get rejected. ## ls -alZd drwxr-x---. defang defang system_u:object_r:sendmail_milter_data_t:s0 /var/spool/MIMEDefang drwxr-x---. defang defang system_u:object_r:sendmail_milter_data_t:s0 /var/spool/MIMEDefang/mdefang-o9BHo6HB006623 ## ps -auxZ mimedefang unconfined_u:system_r:sendmail_milter_t:s0 defang 27377 0.0 0.1 82220 588 ? Sl 12:59 0:00 /usr/bin/mimedefang -P /var/spool/MIMEDefang/mimedefang.pid -m /var/spool/MIMEDefang/mimedefang-multiplexor.sock -R -1 -U defang -q -p /var/spool/MIMEDefang/mimedefang.sock ## cat audit.log type=AVC msg=audit(1288641974.681:21000): avc: denied { create } for pid=27481 comm="mimedefang" name="mdefang-oA1K6DPG027480" scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:sendmail_milter_data_t:s0 tclass=dir
Ok, execute # semanage permissive -a sendmail_milter_t Then try to re-test it. Thanks.
Well that certainly makes it so the errors go away. Not sure what the intent exactly with that is. But if your interested this is the denied audit history for a few tests. type=AVC msg=audit(1288655766.573:21160): avc: denied { create } for pid=28587 comm="mimedefang" name="mdefang-oA1Nu6cZ028586" scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:sendmail_milter_data_t:s0 tclass=dir type=AVC msg=audit(1288655766.658:21161): avc: denied { write } for pid=28531 comm="mimedefang.pl" name="tmp" dev=dm-0 ino=130310 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1288655766.658:21161): avc: denied { add_name } for pid=28531 comm="mimedefang.pl" name="XKnIqRNSCk" scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1288655766.658:21161): avc: denied { create } for pid=28531 comm="mimedefang.pl" name="XKnIqRNSCk" scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288655766.658:21161): avc: denied { read write open } for pid=28531 comm="mimedefang.pl" name="XKnIqRNSCk" dev=dm-0 ino=184775 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288655766.659:21162): avc: denied { ioctl } for pid=28531 comm="mimedefang.pl" path="/tmp/XKnIqRNSCk" dev=dm-0 ino=184775 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288655766.659:21163): avc: denied { getattr } for pid=28531 comm="mimedefang.pl" path="/tmp/XKnIqRNSCk" dev=dm-0 ino=184775 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288655766.660:21164): avc: denied { setattr } for pid=28531 comm="mimedefang.pl" name="XKnIqRNSCk" dev=dm-0 ino=184775 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288655766.665:21165): avc: denied { remove_name } for pid=28531 comm="mimedefang.pl" name="XKnIqRNSCk" dev=dm-0 ino=184775 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir type=AVC msg=audit(1288655766.665:21165): avc: denied { unlink } for pid=28531 comm="mimedefang.pl" name="XKnIqRNSCk" dev=dm-0 ino=184775 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288655766.736:21166): avc: denied { node_bind } for pid=28531 comm="mimedefang.pl" scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:node_t:s0 tclass=udp_socket type=AVC msg=audit(1288655766.739:21167): avc: denied { search } for pid=28531 comm="mimedefang.pl" name="spamassassin" dev=dm-0 ino=394034 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1288655766.739:21167): avc: denied { getattr } for pid=28531 comm="mimedefang.pl" path="/var/lib/spamassassin/3.003001" dev=dm-0 ino=394192 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1288655766.744:21168): avc: denied { read } for pid=28531 comm="mimedefang.pl" name="3.003001" dev=dm-0 ino=394192 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1288655766.744:21168): avc: denied { open } for pid=28531 comm="mimedefang.pl" name="3.003001" dev=dm-0 ino=394192 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=dir type=AVC msg=audit(1288655766.744:21169): avc: denied { getattr } for pid=28531 comm="mimedefang.pl" path="/var/lib/spamassassin/3.003001/updates_spamassassin_org.cf" dev=dm-0 ino=394141 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1288655766.745:21170): avc: denied { read } for pid=28531 comm="mimedefang.pl" name="sought_rules_yerp_org.cf" dev=dm-0 ino=392906 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1288655766.745:21170): avc: denied { open } for pid=28531 comm="mimedefang.pl" name="sought_rules_yerp_org.cf" dev=dm-0 ino=392906 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1288655766.745:21171): avc: denied { ioctl } for pid=28531 comm="mimedefang.pl" path="/var/lib/spamassassin/3.003001/sought_rules_yerp_org.cf" dev=dm-0 ino=392906 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=file type=AVC msg=audit(1288655769.462:21172): avc: denied { getattr } for pid=28587 comm="mimedefang" name="/" dev=dm-0 ino=2 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem type=AVC msg=audit(1288655769.462:21173): avc: denied { rmdir } for pid=28587 comm="mimedefang" name="Work" dev=dm-0 ino=393386 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:sendmail_milter_data_t:s0 tclass=dir type=AVC msg=audit(1288656101.932:21183): avc: denied { create } for pid=28531 comm="mimedefang.pl" name="CiiPpA6vVX" scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288656101.932:21183): avc: denied { read write open } for pid=28531 comm="mimedefang.pl" name="CiiPpA6vVX" dev=dm-0 ino=184870 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288656101.933:21184): avc: denied { ioctl } for pid=28531 comm="mimedefang.pl" path="/tmp/CiiPpA6vVX" dev=dm-0 ino=184870 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288656101.933:21185): avc: denied { getattr } for pid=28531 comm="mimedefang.pl" path="/tmp/CiiPpA6vVX" dev=dm-0 ino=184870 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288656101.933:21186): avc: denied { setattr } for pid=28531 comm="mimedefang.pl" name="CiiPpA6vVX" dev=dm-0 ino=184870 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file type=AVC msg=audit(1288656101.935:21187): avc: denied { unlink } for pid=28531 comm="mimedefang.pl" name="CiiPpA6vVX" dev=dm-0 ino=184870 scontext=unconfined_u:system_r:sendmail_milter_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
(In reply to comment #9) > Well that certainly makes it so the errors go away. Not sure what the intent > exactly with that is. But if your interested this is the denied audit history > for a few tests. The command makes the sendmail_milter_t domain as permissive domain. This means while SELinux access ckecks are performed for this domain, they are not enforced. We can push out a new policy as permissive domain and simply collect AVC messages. Users don’t have to switch to permissive mode globally and they can stay in the enforcing mode.
I have just done another scratch build which should fix all your issues. http://koji.fedoraproject.org/koji/taskinfo?taskID=2571279
Sorry, the build has been aged (removed). Can you do another? Thanks.
Yes, there are: http://koji.fedoraproject.org/koji/taskinfo?taskID=2604131
Sorry, didn't grab it in time. Can you put the .srpm in your directory on fedorapeople.org and I'll build it myself? Thanks. BTW: What's the progress of this fix? What's it waiting on?
Fixed in selinux-policy-3.7.19-77.fc13
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.