Bug 447247

Created attachment 305893 [details]
Mail from spamassassin-milter

Created attachment 305894 [details]
Mail from spamassassin-milter

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.

I can confirm is a selinux issue: the service run OK with selinux in permissive mode

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?

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.

Does restorecon exit silently with 0 exit status if selinux is disabled?

From setfiles.c (restorecon)

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

spamass-milter-0.3.1-8.fc9 has been submitted as an update for Fedora 9

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

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

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.

Check out in selinux-policy-3.3.1-55.fc9

there were some fixes for this.

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.

(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.

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.

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

Created attachment 307262 [details]
Local policy for spmassassin avcs

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.

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.

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.

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.

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

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

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

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.

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.