David,
does it work with your local policy?

Yes, the following is working.

module myspamassin 1.0;

require {
        type spamc_t;
        type bin_t;
        class file execute;
}

#============= spamc_t ==============
allow spamc_t bin_t:file execute;

Fixed in selinux-policy-3.9.7-23.fc14

Apparently we did not wait long enough to trigger all the avs issues. The local policy is now as follows:

module myspamassin 1.0;

require {
	type spamc_t;
	type bin_t;
	type user_home_t;
	class dir { read write };
	class file { read write execute };
}

#============= spamc_t ==============
#!!!! This avc is allowed in the current policy

allow spamc_t bin_t:file execute;
#!!!! The source type 'spamc_t' can write to a 'dir' of the following types:
# spamc_home_t, amavis_var_lib_t, amavis_spool_t, tmp_t, user_home_dir_t, spamass_milter_state_t, spamc_tmp_t, nfs_t

allow spamc_t user_home_t:dir { read write };
allow spamc_t user_home_t:file { read write };

These look like leaks.  What tool were you using to launch spam?

Notice you are not asking for open.

allow spamc_t user_home_t:dir { read write };
allow spamc_t user_home_t:file { read write };

Good thing we checked our selfs on this, we are invoking it via procmail, we had remembered it as being via sendmail. Typical user .procmailrc file:

INCLUDERC=/etc/mail/spamassassin/spamassassin.rc

:0:
    * ^X-Spam-Level: \*\*
    Mail/spamlog

:0:
    * ^X-Spam-Status: Yes
    Mail/spamlog

:0:
    * ^Subject: \[SPAM\] \=\?[Ww]indows
    Mail/spamlog

And the file /etc/mail/spamassassin/spamassassin.rc:
# send mail through spamassassin
:0fw
| /usr/bin/spamassassin

Which we believe is the latest out of the box configuration for sendmail and spamassassin filtering.

So this looks like procmail is leakind open file descriptors to files in the homedir.  If you change your allow rules to dontaudit, does the spam check still work?

We have run for about 12 hours with the local policy below and it is working. We were not clear if we should have changed the line
allow spamc_t bin_t:file execute;
to
dontaudit spamc_t bin_t:file execute;




module myspamassin 1.0;

require {
	type spamc_t;
	type bin_t;
	type user_home_t;
	class dir { read write };
	class file { read write execute };
}

#============= spamc_t ==============
#!!!! This avc is allowed in the current policy

dontaudit spamc_t bin_t:file execute;
#!!!! The source type 'spamc_t' can write to a 'dir' of the following types:
# spamc_home_t, amavis_var_lib_t, amavis_spool_t, tmp_t, user_home_dir_t, spamass_milter_state_t, spamc_tmp_t, nfs_t

dontaudit spamc_t user_home_t:dir { read write };
dontaudit spamc_t user_home_t:file { read write };

Miroslav add the dontaudits and allow spamc to execute bin_t.

I have already added 

corecmd_exec_bin(spamc_t)


Will add

dontaudit spamc_t user_home_t:dir { read write };
dontaudit spamc_t user_home_t:file { read write };

selinux-policy-3.9.7-25.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-25.fc14

selinux-policy-3.9.7-25.fc14 has been pushed to the Fedora 14 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 selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-25.fc14

We updated to the policy in test above, removed our local policy and all is working. Did this fix open a whole in selinux where procmail should have been changed instead or is it an edge case where either place would be the right fix?

No it should be fixed in procmail still, we are just not reporting the leak.

Procmail should make sure that files opened be closed on exec.

fcntl(fd, F_SETFD, FD_CLOEXEC)

selinux-policy-3.9.7-25.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.