Description of problem: Using default rpm installation, none of the supplied milters work. All result in socket unsafe message; for example: sendmail[20025]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1782: Xmimedefang: local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe: Permission denied Version-Release number of selected component (if applicable): sendmail-8.14.3-5.fc11.x86_64 mimedefang-2.67-1.fc11.x86_64 spamass-milter-0.3.1-13.fc11.x86_64 How reproducible: Always Steps to Reproduce: 1. Install rpms; configure as per documentation 2. 3. Actual results: socket unsafe messages. Either sendmail fails to start, or the milter is not usable (depending on the parameters used to set up the milter in sendmail). Expected results: That sendmail works and communicates with the milter. Additional info: Besides the default configs, I've tried forcing the milter(s) to run as user smmsp. I've tried just about every permutation of permissions for the directory holding the socket. As the same error message is generated regardless of the presence of the .sock file, I'd guess the issue is with the directory. Initially, I got AVC errors, but added policy to allow the access. I also tried in permissive mode, so selinux is not an issue. There are no pam messages in /var/log/secure that correspond to this issue (although I wouldn't rule pam out as a culprit). The milter lines in sendmail.mc I've been using (not at the same time) are: INPUT_MAIL_FILTER(`spf-milter', `S=local:/var/run/spf-milter/spf-milter.sock, F=T, T=C:4m;S:4m;R:8m;E:16m') INPUT_MAIL_FILTER(`spamass-milter', `S=local:/var/run/spamass-milter/spamass-milter.sock, F=T, T=C:4m;S:4m;R:8m;E:16m') INPUT_MAIL_FILTER(`mimedefang', `S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:1m;R:1m')dnl Current (last) state of the mimedefang directory (the one I messed with the most): -rw-r-----. 1 smmsp smmsp 6 2009-08-08 01:15 mimedefang-multiplexor.pid srw-------. 1 smmsp smmsp 0 2009-08-08 01:15 mimedefang-multiplexor.sock -rw-r-----. 1 smmsp smmsp 6 2009-08-08 01:15 mimedefang.pid srwxr-x---. 1 smmsp smmsp 0 2009-08-08 01:15 mimedefang.sock ls -ld /var/spool/MIMEDefang/ drwx------. 2 smmsp mail 4096 2009-08-08 01:15 /var/spool/MIMEDefang/ spamass: ls -ld /var/run/spamass-milter drwx--x--x. 2 sa-milt sa-milt 4096 2009-08-05 13:48 /var/run/spamass-milter ls -l /var/run/spamass-milter total 0 srwxr-xr-x. 1 sa-milt sa-milt 0 2009-08-05 13:48 spamass-milter.sock etc.
I'm not sure what's wrong. Except the two AVC denials for mimedefang it seems to work fine here, including spamass-milter. The only configuration I did was enabling the milters in sendmail.mc. The missing rule is: allow sendmail_t spamd_spool_t:sock_file { write getattr }; My listings: drwxr-x---. 3 defang defang 4096 Aug 11 17:57 . drwxr-xr-x. 17 root root 4096 Aug 11 17:39 .. drwx------. 2 defang defang 4096 Aug 11 17:57 .spamassassin -rw-r-----. 1 defang defang 6 Aug 11 17:49 mimedefang-multiplexor.pid srw-------. 1 defang defang 0 Aug 11 17:49 mimedefang-multiplexor.sock -rw-r-----. 1 defang defang 6 Aug 11 17:49 mimedefang.pid srwxr-x---. 1 defang defang 0 Aug 11 17:49 mimedefang.sock drwx--x--x. 2 sa-milt sa-milt 4096 Aug 11 17:56 . drwxr-xr-x. 29 root root 4096 Aug 11 17:57 .. srwxr-xr-x. 1 sa-milt sa-milt 0 Aug 11 17:56 spamass-milter.sock
Ok - out of curiosity, what build of sendmail? Selinux is set (no AVC denials). When I ran the debug version of sendmail under gdb with a breakpoint at safefile, I didn't get the error (of course). Without the breakpoint I do get the error. Perhaps there is a build-specific GCC or optimization issue (I haven't rebuilt sendmail yet, just used the fedora-updates rpm. I do have everything working using TCP sockets, just can't get the Unix domain sockets to function. Also note that the unix sockets DO work between clamd and clamav-milter, and between mimedefang and both clamav and spamassassin. Likewise, Spamassassin speaks to spamassassin-milter. Just sendmail doesn't work.
That's odd. Maybe you could try recompiling with -O0 to see if it's really an optimization issue? I did the test with same package versions as in comment #0, also on x86_64.
I recompiled with debug flags (build -v debug). It works. Same bits compiled -O2 do not work. I hate these bugs.
So since it works for you on X86-64, and with all else being equal, maybe it's a chip level difference. I'm on a Core i7 920 D stepping with HT and Virt enabled. [Been a really long time since I disassembled something looking for an optimizer error :(]
I have a Core2 here. Can you try rpm -qV sendmail to see if it's not some random bit flipped on disk?
S.5....T. c /etc/mail/access S.5....T. c /etc/mail/domaintable S.5....T. c /etc/mail/local-host-names S.5....T. c /etc/mail/mailertable S.5....T. c /etc/mail/sendmail.cf S.5....T. c /etc/mail/sendmail.mc S.5....T. c /etc/mail/trusted-users S.5....T. /usr/sbin/sendmail.sendmail S.5....T. c /var/log/mail/statistics comments: sendmail.sendmail is currently the debug version (was flipping the binaries around). The rest of the files are necessarily different due to local config, appear correct and work with the non-optimized binary for sendmail.
Ok - did more digging. So service /etc/rc.d/init.d/sendmail gives the error (no matter which binary). Running the binary by hand (or in gdb) works. /etc/rc.d/init.d/sendmail start also fails But... sh /etc/rc.d/init.d/sendmail works. Never looking into how shell scripts are actually executed under the covers (i.e., what is the real difference between ./<file> and sh <file> when execute permissions are set. Note: permissions on /etc/rc.d/init.d/sendmail: -rwxr-xr-x. 1 root root 3614 2009-08-12 15:08 sendmail So... nothing obvious.
So - one more hint... I ran with -D/tmp/smlog -d44,47 when run sh <...>/sendmail, I get proper trace messages in /tmp/smlog: drop_privileges(0): Real[UG]id=0:0, get[ug]id=0:0, gete[ug]id=0:0, RunAs[UG]id=0:0 When run with the service command (or /etc/.../sendmail), I get the /tmp/smlog file created, but it's empty. Additionally, I ran with loglevel=99. When run with sh <...>, I get lots of messages - including a print of the command line. When run with service, I only get the unsafe sock message - no other log messages (anywhere) or debug info.
Getting different results when using sh /etc/init.d/sendmail would suggest a SELinux problem. Did you try switching it to permissive mode (setenforce 0)?
Ok, that indeed solves the issue. Oddly, while enforcing, I had no avc errors in either syslog or the audit log - just failed to use the socket. In permissive mode, I get plenty of warnings regarding the socket. I'll build a new ruleset and see if it works. Here are the avc errors I see when in permissive mode: type=AVC msg=audit(1250186264.701:23743): avc: denied { getattr } for pid=23893 comm="sendmail" path="/var/spool/MIMEDefang/mimedefang.sock" dev=dm-1 ino=41708 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:spamd_spool_t:s0 tclass=sock_file type=AVC msg=audit(1250186335.656:23744): avc: denied { getattr } for pid=24002 comm="sendmail" path="/var/spool/MIMEDefang/mimedefang.sock" dev=dm-1 ino=41708 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:spamd_spool_t:s0 tclass=sock_file type=AVC msg=audit(1250186335.656:23745): avc: denied { write } for pid=24002 comm="sendmail" name="mimedefang.sock" dev=dm-1 ino=41708 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:spamd_spool_t:s0 tclass=sock_file type=AVC msg=audit(1250186350.049:23746): avc: denied { getattr } for pid=24013 comm="sendmail" path="/var/spool/MIMEDefang/mimedefang.sock" dev=dm-1 ino=41708 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:spamd_spool_t:s0 tclass=sock_file type=AVC msg=audit(1250186350.049:23747): avc: denied { write } for pid=24013 comm="sendmail" name="mimedefang.sock" dev=dm-1 ino=41708 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:spamd_spool_t:s0 tclass=sock_file
Ok - added the rules, got rid of all avc errors in permissive mode. Switched back to enforcing, unsafe sock error returns. There are no AVC errors in /var/log/messages or /var/log/audit/audit.log or dmesg subsequent to the setenforce 1. Not sure where to go from here.
# semanage permissive -a sendmail_t # semodule -DB run your command Look for sendmail avc's Generate policy # semanage permissive -d sendmail_t # semodule -B But I think the problem might be the locataion of the mimedefang.sock. Adding Paul Howard, who understands this stuff better then me.
Don't know about mimedefang as I don't use it but there should be no problems with spamass-milter. Can you post the output of: # ls -lZd $(rpm -ql spamass-milter) | grep -v share Here's what I get: -rwxr-xr-x. root root system_u:object_r:initrc_exec_t:s0 /etc/rc.d/init.d/spamass-milter -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/sysconfig/spamass-milter -rwxr-xr-x. root root system_u:object_r:spamass_milter_exec_t:s0 /usr/sbin/spamass-milter -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/sbin/spamass-milter-wrapper drwxr-xr-x. sa-milt sa-milt system_u:object_r:spamass_milter_state_t:s0 /var/lib/spamass-milter drwx--x--x. sa-milt sa-milt system_u:object_r:spamass_milter_data_t:s0 /var/run/spamass-milter Are you still getting errors with spamass-milter? You might also want to post the output from the equivalent "ls" command from above for mimedefang; it may be useful.
Ok. Paul: output from the ls for mimedefang (and the sock file) below. Just rechecked spamass - it's working now; only mimedefang seems still broken. Daniel: That helped... now I get AVCs... many of them... had no idea so much stuff was being silently denied - included the messages below. I created policy based on this and the issue is now resolved. The policy that seemed to do the trick is: allow sendmail_t spamd_spool_t:dir { search getattr }; allow sendmail_t spamd_spool_t:sock_file { write getattr }; allow sendmail_t unconfined_t:unix_stream_socket connectto; although audit2allow also supplied (and I loaded): allow sendmail_t device_t:file open; allow sendmail_t devpts_t:chr_file write; allow sendmail_t security_t:file { read open }; allow sendmail_t selinux_config_t:dir search; allow sendmail_t selinux_config_t:file { read getattr open }; Relevant seem to be: (audit.log) avc: denied { search } for pid=30477 comm="sendmail" name="MIMEDefang" dev=dm-1 ino=40623 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:spamd_spool_t:s0 tclass=dir avc: denied { getattr } for pid=30477 comm="sendmail" path="/var/spool/MIMEDefang" dev=dm-1 ino=40623 scontext=unconfined_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:spamd_spool_t:s0 tclass=dir (syslog) setroubleshoot: SELinux is preventing sendmail (sendmail_t) "getattr" spamd_spool_t. For complete SELinux messages. run sealert -l 7699c63b-2be3-4f0b-b0bb-71aede706a40 setroubleshoot: SELinux is preventing sendmail (sendmail_t) "search" spamd_spool_t. For complete SELinux messages. run sealert -l f85389c5-9aba-4a7b-afdb-98ad0e21e7ab ls output -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/logrotate.d/mimedefang -rw-r--r--. root root system_u:object_r:etc_mail_t:s0 /etc/mail/mimedefang-filter -rw-r--r--. root root unconfined_u:object_r:etc_mail_t:s0 /etc/mail/mimedefang-ip-key lrwxrwxrwx. root root unconfined_u:object_r:etc_mail_t:s0 /etc/mail/sa-mimedefang.cf -> /etc/mail/spamassassin/local.cf -rwxr-xr-x. root root system_u:object_r:spamd_initrc_exec_t:s0 /etc/rc.d/init.d/mimedefang -rw-r--r--. root root system_u:object_r:etc_t:s0 /etc/sysconfig/mimedefang -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/gen-ip-validator.pl -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/md-mx-ctrl -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/mimedefang -rwxr-xr-x. root root system_u:object_r:spamd_exec_t:s0 /usr/bin/mimedefang-multiplexor -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/mimedefang.pl -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/watch-mimedefang -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/watch-multiple-mimedefangs.tcl drwxr-x---. defang defang system_u:object_r:var_log_t:s0 /var/log/mimedefang drwxr-x---. defang defang system_u:object_r:spamd_spool_t:s0 /var/spool/MD-Quarantine drwxr-x---. defang defang system_u:object_r:spamd_spool_t:s0 /var/spool/MIMEDefang [root@mail MIMEDefang]# ls -lZd /var/spool/MIMEDefang/ drwxr-x---. defang defang system_u:object_r:spamd_spool_t:s0 /var/spool/MIMEDefang/ [root@mail MIMEDefang]# ls -lZd /var/spool/MIMEDefang/* -rw-r-----. defang defang unconfined_u:object_r:spamd_spool_t:s0 /var/spool/MIMEDefang/mimedefang-multiplexor.pid srw-------. defang defang unconfined_u:object_r:spamd_spool_t:s0 /var/spool/MIMEDefang/mimedefang-multiplexor.sock -rw-r-----. defang defang unconfined_u:object_r:spamd_spool_t:s0 /var/spool/MIMEDefang/mimedefang.pid srwxr-x---. defang defang unconfined_u:object_r:spamd_spool_t:s0 /var/spool/MIMEDefang/mimedefang.sock
(In reply to comment #15) > Ok. > > Paul: output from the ls for mimedefang (and the sock file) below. Just > rechecked spamass - it's working now; only mimedefang seems still broken. Good, so we're limited to mimedefang+selinux as the broken combination then. => Daniel: That helped... now I get AVCs... many of them... had no idea so much > stuff was being silently denied - included the messages below. > > I created policy based on this and the issue is now resolved. > > The policy that seemed to do the trick is: > allow sendmail_t spamd_spool_t:dir { search getattr }; > allow sendmail_t spamd_spool_t:sock_file { write getattr }; > allow sendmail_t unconfined_t:unix_stream_socket connectto; > > although audit2allow also supplied (and I loaded): > allow sendmail_t device_t:file open; > allow sendmail_t devpts_t:chr_file write; > allow sendmail_t security_t:file { read open }; > allow sendmail_t selinux_config_t:dir search; > allow sendmail_t selinux_config_t:file { read getattr open }; > > Relevant seem to be: > (audit.log) > avc: denied { search } for pid=30477 comm="sendmail" name="MIMEDefang" > dev=dm-1 ino=40623 scontext=unconfined_u:system_r:sendmail_t:s0 > tcontext=system_u:object_r:spamd_spool_t:s0 tclass=dir > avc: denied { getattr } for pid=30477 comm="sendmail" > path="/var/spool/MIMEDefang" dev=dm-1 ino=40623 > scontext=unconfined_u:system_r:sendmail_t:s0 > tcontext=system_u:object_r:spamd_spool_t:s0 tclass=dir > (syslog) > setroubleshoot: SELinux is preventing sendmail (sendmail_t) "getattr" > spamd_spool_t. For complete SELinux messages. run sealert -l > 7699c63b-2be3-4f0b-b0bb-71aede706a40 > setroubleshoot: SELinux is preventing sendmail (sendmail_t) "search" > spamd_spool_t. For complete SELinux messages. run sealert -l > f85389c5-9aba-4a7b-afdb-98ad0e21e7ab > > ls output > -rw-r--r--. root root system_u:object_r:etc_t:s0 > /etc/logrotate.d/mimedefang > -rw-r--r--. root root system_u:object_r:etc_mail_t:s0 > /etc/mail/mimedefang-filter > -rw-r--r--. root root unconfined_u:object_r:etc_mail_t:s0 > /etc/mail/mimedefang-ip-key > lrwxrwxrwx. root root unconfined_u:object_r:etc_mail_t:s0 > /etc/mail/sa-mimedefang.cf -> /etc/mail/spamassassin/local.cf > -rwxr-xr-x. root root system_u:object_r:spamd_initrc_exec_t:s0 > /etc/rc.d/init.d/mimedefang > -rw-r--r--. root root system_u:object_r:etc_t:s0 > /etc/sysconfig/mimedefang > -rwxr-xr-x. root root system_u:object_r:bin_t:s0 > /usr/bin/gen-ip-validator.pl > -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/md-mx-ctrl > -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/mimedefang > -rwxr-xr-x. root root system_u:object_r:spamd_exec_t:s0 > /usr/bin/mimedefang-multiplexor > -rwxr-xr-x. root root system_u:object_r:bin_t:s0 > /usr/bin/mimedefang.pl > -rwxr-xr-x. root root system_u:object_r:bin_t:s0 > /usr/bin/watch-mimedefang > -rwxr-xr-x. root root system_u:object_r:bin_t:s0 > /usr/bin/watch-multiple-mimedefangs.tcl > drwxr-x---. defang defang system_u:object_r:var_log_t:s0 /var/log/mimedefang > drwxr-x---. defang defang system_u:object_r:spamd_spool_t:s0 > /var/spool/MD-Quarantine > drwxr-x---. defang defang system_u:object_r:spamd_spool_t:s0 > /var/spool/MIMEDefang > [root@mail MIMEDefang]# ls -lZd /var/spool/MIMEDefang/ > drwxr-x---. defang defang system_u:object_r:spamd_spool_t:s0 > /var/spool/MIMEDefang/ > [root@mail MIMEDefang]# ls -lZd /var/spool/MIMEDefang/* > -rw-r-----. defang defang unconfined_u:object_r:spamd_spool_t:s0 > /var/spool/MIMEDefang/mimedefang-multiplexor.pid > srw-------. defang defang unconfined_u:object_r:spamd_spool_t:s0 > /var/spool/MIMEDefang/mimedefang-multiplexor.sock > -rw-r-----. defang defang unconfined_u:object_r:spamd_spool_t:s0 > /var/spool/MIMEDefang/mimedefang.pid > srwxr-x---. defang defang unconfined_u:object_r:spamd_spool_t:s0 > /var/spool/MIMEDefang/mimedefang.sock So what we have here is sendmail trying to talk to mimedefang, where the latter is a service that's using the generic spamd_t domain. It's putting its PID files and sockets in /var/spool/MIMEDefang, which results in them getting labelled spamd_spool_t, which sendmail can't currently use. It might be nice to get it to put PID files under /var/run but that's a side issue. Does mimedefang put anything else under /var/spool/MIMEDefang other than the pid files and sockets when it's running? Possibly the simplest fix would be to add the milter_data_type attribute to spamd_spool_t, which should let sendmail/postfix use sockets of that type.
Yes - Mimedefang creates additional files in /var/spool/MIMEDefang: mimedefang-multiplexor.pid mimedefang-multiplexor.sock mimedefang.pid mimedefang.sock That does seem like a reasonable fix.
Nothing else *other than* the PIDs and the socks though? If that's the case, it would be nice to split these off as a different type rather than lumping them with everything else that's spamd_spool_t.
Michael, if you simply change the context of /var/spool/MIMEDefang to spamd_var_run_t does everything work? chcon -t spamd_var_run_t -R /var/spool/MIMEDefang
I'll check it out later today after I figure out how to remove the rules I added that are currently allowing access.
semodule -r MYPOL
Thanks - saved a few min... The context change in fact solved the issue. I deleted the policy, verified the sock unsafe issue returned, then changed the context and verified that sendmail started correctly using the local socket. Thank you for help.
Miroslav can you change the labels on /var/spool/MIME* to be spamd_var_run_t.
I will fix it in selinux-policy-3.6.12-79.fc11
Michael, current F-11 policy is selinux-policy-3.6.12-88.fc11; does this one work for you without local context fixes? You could do this to assign default contexts for testing: # restorecon -rvF /var/spool/MIMEDefang
Actually, I've moved to F12... I'd be happy to retest with the corresponding F12 fix.
I'm running with selinux-policy-3.6.32-46.fc12, which has contexts for /var/spool/MIMEDefang: # semanage fcontext -l | grep -i mime /etc/rc\.d/init\.d/mimedefang.* regular file system_u:object_r:spamd_initrc_exec_t:s0 /usr/bin/mimedefang-multiplexor regular file system_u:object_r:spamd_exec_t:s0 /var/log/mimedefang regular file system_u:object_r:spamd_log_t:s0 /var/spool/MIMEDefang(/.*)? all files system_u:object_r:spamd_var_run_t:s0 So that should be OK.
Ok- tested with the restorecon -rfF /var/spool/MIMEDefang and then reinstaned selinux-policy-3.6.32-46.fc12. Looks good.