Bug 447247 - service spamass-milter doesn´t work
service spamass-milter doesn´t work
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: spamass-milter (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
: Reopened
Depends On: 483849
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-19 00:15 EDT by Esteban Xandri
Modified: 2009-04-24 15:54 EDT (History)
1 user (show)

See Also:
Fixed In Version: 0.3.1-13.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-23 06:16:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Mail from spamassassin-milter (442 bytes, text/plain)
2008-05-19 00:15 EDT, Esteban Xandri
no flags Details
Mail from spamassassin-milter (442 bytes, text/plain)
2008-05-19 00:20 EDT, Esteban Xandri
no flags Details
Local policy for spmassassin avcs (627 bytes, text/plain)
2008-05-31 01:00 EDT, Esteban Xandri
no flags Details

  None (edit)
Description Esteban Xandri 2008-05-19 00:15:11 EDT
Description of problem:
After an upgrade from F8, service spamass-milter refuses to start

Version-Release number of selected component (if applicable):
spamass-milter-0.3.1-7.fc9.i386

How reproducible:
Always

Steps to Reproduce:
1.service spamass-milter start
Starting SpamAssassin milter (spamass-milter):             [  OK  ]
2.service spamass-milter status
spamass-milter dead but pid file exists
3.service spamass-milter stop
Shutting down SpamAssassin milter (spamass-milter):        [FAILED]

Actual results:
mail box flooded with (see attachment) messages


Expected results: spamass-milter working properly


Additional info:

It worked fine on F8. I investigated a bit and I suspect there is a permission
problem when spamass-milter try to create the pidfile (spamass-milter.pid)  on
/var/run/ directory, as sa-milt user.
Comment 1 Esteban Xandri 2008-05-19 00:15:12 EDT
Created attachment 305893 [details]
Mail from spamassassin-milter
Comment 2 Esteban Xandri 2008-05-19 00:20:30 EDT
Created attachment 305894 [details]
Mail from spamassassin-milter
Comment 3 Paul Howarth 2008-05-19 12:09:55 EDT
This appears to be an selinux issue; doing "setenforce 0" allows the service to
start here. I'll look into a proper fix for this, which will probably involve a
change to policy.
Comment 4 Esteban Xandri 2008-05-19 19:36:16 EDT
I can confirm is a selinux issue: the service run OK with selinux in permissive mode
Comment 5 Paul Howarth 2008-05-20 07:50:30 EDT
My proposed fix is this:

Add a context to selinux-policy, equivalent to doing:
semanage fcontext -a -t spamd_var_run_t -f -- /var/run/spamass-milter\.pid

Make the following change to the initscript:
--- /etc/rc.d/init.d/spamass-milter.orig	2008-05-20 12:48:02.000000000 +0100
+++ /etc/rc.d/init.d/spamass-milter	2008-05-20 12:38:24.000000000 +0100
@@ -44,6 +44,9 @@
 	echo -n $"Starting ${desc} (${prog}): "
 	touch ${pidfile}
 	chown sa-milt:sa-milt ${pidfile}
+	if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then
+		/sbin/restorecon ${pidfile}
+	fi
 	daemon --user sa-milt /usr/sbin/${prog}-wrapper -p ${SOCKET} -P ${pidfile}
${EXTRA_FLAGS}
 	RETVAL=$?
 	echo


The restorecon snippet here is similar to the one in the sendmail initscript for
creating the sm-client pidfile.

Dan, does this look sensible?

Comment 6 Daniel Walsh 2008-05-20 11:33:04 EDT
Yes I am adding the file context

I would just add

[ -x /sbin/restorecon ] && /sbin/restorecon ${pidfile}

Restorecon checks whether selinux is enabled internally.

Policy selinux-policy-3.3.1-53 has the fix.
Comment 7 Paul Howarth 2008-05-20 11:36:20 EDT
Does restorecon exit silently with 0 exit status if selinux is disabled?
Comment 8 Daniel Walsh 2008-05-20 15:31:39 EDT
From setfiles.c (restorecon)

		/* restorecon only:  silent exit if no SELinux.
		   Allows unconditional execution by scripts. */
		if (is_selinux_enabled() <= 0)
			exit(0);


Comment 9 Fedora Update System 2008-05-20 19:06:34 EDT
spamass-milter-0.3.1-8.fc9 has been submitted as an update for Fedora 9
Comment 10 Paul Howarth 2008-05-20 19:10:30 EDT
Packages are now built and awaiting the push to testing. For now, you can get
them here:

selinux-policy:
http://koji.fedoraproject.org/koji/buildinfo?buildID=49920

spamass-milter:
http://koji.fedoraproject.org/koji/buildinfo?buildID=49928
Comment 11 Fedora Update System 2008-05-22 16:38:10 EDT
spamass-milter-0.3.1-8.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update spamass-milter'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4368
Comment 12 Paul Howarth 2008-05-27 05:33:43 EDT
Esteban, is spamass-milter actually running OK for you? I'm getting loads of
SELinux denials now that I'm on Fedora 9 with my mail server, as spamass-milter,
which runs in SELinux context type spamd_t, calls spamc, which isn't currently
provided for in policy.

I think I may be better off writing a custom policy for spamass-milter.
Comment 13 Daniel Walsh 2008-05-27 15:00:55 EDT
Check out in selinux-policy-3.3.1-55.fc9

there were some fixes for this.
Comment 14 Esteban Xandri 2008-05-27 17:53:01 EDT
Paul:
So far so good: I updated selinux-policy & spamass-milter, as suggested in
Comment #10, and that was enough to fix the problem. Right now I have 
spamass-milter-0.3.1-8.fc9.i386
selinux-policy-3.3.1-55.fc9.noarch
selinux-policy-devel-3.3.1-55.fc9.noarch
selinux-policy-targeted-3.3.1-55.fc9.noarch
installed, and spamass-milter is working fine without any avc denial detected.

Comment 15 Paul Howarth 2008-05-27 19:39:18 EDT
(In reply to comment #13)
> Check out in selinux-policy-3.3.1-55.fc9
> 
> there were some fixes for this.

I'm already using selinux-policy-3.3.1-55.fc9; it fixes the startup problem but
I got loads of new AVCs that resulted in these rules:

# spamass-milter calling spamc?
spamassassin_exec_client(spamd_t)
sendmail_rw_tcp_sockets(spamc_t)
sendmail_rw_unix_stream_sockets(spamc_t)
spamassassin_read_lib_files(spamc_t)
corenet_tcp_connect_spamd_port(spamd_t)

I'm still getting some other AVCs that I've not investigated yet:

type=AVC msg=audit(1211929219.971:3510): avc:  denied  { execute } for 
pid=26003 comm="spamass-milter" name="bash" dev=dm-0 ino=80018
scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:shell_exec_t:s0
tclass=file
type=SYSCALL msg=audit(1211929219.971:3510): arch=40000003 syscall=11 success=no
exit=-13 a0=92023f a1=b4343194 a2=bfd518a8 a3=3 items=0 ppid=6189 pid=26003
auid=4294967295 uid=496 gid=495 euid=496 suid=496 fsuid=496 egid=495 sgid=495
fsgid=495 tty=(none) ses=4294967295 comm="spamass-milter"
exe="/usr/sbin/spamass-milter" subj=system_u:system_r:spamd_t:s0 key=(null)

I think this one is triggered in a "learn as spam" situation.
It looks far too dangerous to allow though.

type=AVC msg=audit(1211929514.578:3547): avc:  denied  { append } for  pid=26302
comm="spamc" path="/home/paul/.nospam/procmail.log" dev=dm-12 ino=3148799
scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=file
type=SYSCALL msg=audit(1211929514.578:3547): arch=40000003 syscall=11
success=yes exit=0 a0=bffde3c3 a1=83dc928 a2=83dcc58 a3=83dc520 items=0
ppid=26301 pid=26302 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500
egid=500 sgid=500 fsgid=500 tty=(none) ses=4294967295 comm="spamc"
exe="/usr/bin/spamc" subj=system_u:system_r:spamc_t:s0 key=(null)

Either or both of these (and maybe even the ones I've done the local rules for
above) might actually be coming from my procmail rules rather than
spamass-milter - I have rules that feed mail into spamc for learning when my own
hand-rolled procmail-based spam filter is convinced that a message is spam. I'll
try disabling those rules and see if the AVCs go away.

Comment 16 Paul Howarth 2008-05-28 12:24:28 EDT
I think I've found the shell exec: if you use the -b or -B options in
spamass-milter to redirect spam to a specific mailbox, the milter opens a pipe
with popen() and calls sendmail to deliver the message.

I really do think a separate policy is going to be needed here rather than
sharing spamd_t with spamassassin.
Comment 17 Esteban Xandri 2008-05-31 00:58:18 EDT
Paul:
My bad: Comment #12 is correct. Spamass-milter is flooding logs w/avc denials. 
I didn't remember the fact that I had (from F8)  a local policy enabled in order
to get rid of them (see attachment myspam.te ).
If I remove the policy, I get lots of avc denials
I guess I will keep the local policy until the fix of Comment #16 is finished
Comment 18 Esteban Xandri 2008-05-31 01:00:28 EDT
Created attachment 307262 [details]
Local policy for spmassassin avcs
Comment 19 Paul Howarth 2008-06-05 05:08:19 EDT
I posted my first pass at a new policy for spamass-milter (and milter-regex too)
here:

http://www.redhat.com/archives/fedora-selinux-list/2008-June/msg00007.html

Using this policy, I've not had a single AVC related to mail since I installed
it a couple of days ago. Since it separates spamass-milter from spamassassin so
that they are separately confined, there are currently some conflicts in the
file contexts with the main selinux-policy package that result in warnings
though they don't actually cause any problems that I can see. If you want to try
the new policy (and I'd appreciate feedback on it), you'll need to change the
contexts of /usr/sbin/spamass-milter and /var/run/spamass-milter and its
contents after installing the policy (restorecon -rv should work), and then
restart the milter.
Comment 20 Fedora Update System 2008-06-06 03:51:09 EDT
spamass-milter-0.3.1-8.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Paul Howarth 2008-07-04 10:21:48 EDT
I've updated my SELinux policy for spamass-milter: see Bug #452248

I'm in the process of trying to get the policy updated in selinux-policy upstream.
Comment 22 Fedora Update System 2008-07-26 02:06:06 EDT
spamass-milter-0.3.1-8.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Paul Howarth 2009-02-03 16:56:59 EST
Reopening since there are still issues with SELinux here.

I have requested that my milter SELinux policy module be added to Fedora 9 and 10 policy (it is already in Rawhide) in Bug #483849
Comment 24 Fedora Update System 2009-04-03 11:43:33 EDT
spamass-milter-0.3.1-13.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc10
Comment 25 Fedora Update System 2009-04-03 11:47:11 EDT
spamass-milter-0.3.1-13.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc9
Comment 26 Fedora Update System 2009-04-22 16:28:06 EDT
spamass-milter-0.3.1-13.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Fedora Update System 2009-04-24 15:54:48 EDT
spamass-milter-0.3.1-13.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.