It looks like also spamc_t need to read spamass_milter_state_t.

So spamd transitions from spamd_t to spamc_t when running pyzor (and presumably razor too)?

That would explain the need for the milter_manage_data interface I was asking about in https://bugzilla.redhat.com/show_bug.cgi?id=483849#c5

There is explanation why milter_manage_data was needed:

https://bugzilla.redhat.com/show_bug.cgi?id=474183#c3

Yes Paul I am trying to combine all spam handling apps into a single context.

I understand the combining of razor, pyzor etc. into one domain; what I was a little surprised about was the transition from the daemon domain spamd_t into the client domain spamc_t - that is what's happening, isn't it?

optional_policy(`
	pyzor_domtrans(spamd_t)
	pyzor_signal(spamd_t)
')

optional_policy(`
	razor_domtrans(spamd_t)
	razor_read_lib_files(spamd_t)
	tunable_policy(`spamd_enable_home_dirs',`
		razor_manage_user_home_files(spamd_t)
	')
')

Yup.

(In reply to comment #6)
> optional_policy(`
>  pyzor_domtrans(spamd_t)
>  pyzor_signal(spamd_t)
> ')
> 
> optional_policy(`
>  razor_domtrans(spamd_t)
>  razor_read_lib_files(spamd_t)
>  tunable_policy(`spamd_enable_home_dirs',`
>   razor_manage_user_home_files(spamd_t)
>  ')
> ')
> 
> Yup.  

Should I add this somewhere?

Regards,

Eddie.

You don't have to add this. 


I will fix the problem with spamc_t and spamass_milter_state_t. You can add these rules for now using

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

I'm planning on sending an updated version of the milter policy patch that addresses this and Bug #489995 upstream shortly (the original patch already seems to have been applied in F-10). I'm going to change the name of the spamass_milter_manage_state interface to milter_spamass_manage_state as I believe that fits upstream's naming convention better, and add milter_spamass_manage_state(spamc_t) to spamassassin.te.

Fixed in selinux-policy-3.5.13-54.fc10

F-10 looks good now but F-9 policy still has interface spamass_milter_manage_state rather than milter_spamass_manage_state and is missing the call to this interface for spamc_t - can we fix that too?

I will fix it in F9 too.

Fix is added to selinux-policy-3.3.1-131.fc9

Great stuff Miroslav - thanks; that just leaves Rawhide needing an update. Will Rawhide policy pull from upstream again before F11 release?

Not that upstream has merged my patch yet anyway...

Yes,  We we will pull at least one more time.

Thank you for the solution, it seems to be solved now.

regards,

Eddie.

I see that RHEL 5 has the spamc_t domain and associated rules from RHEL 5.3; is there any chance of adding the milter policy for RHEL 5.4? spamass-milter in EPEL could do with it.

Paul,

selinux-policy-2.4.6-224.el5.noarch.rpm

is out on http://people.redhat.com/dwalsh/RHEL5

Which has a totally untested milter policy on it, could you do a quick test?

(In reply to comment #14)
> Great stuff Miroslav - thanks; that just leaves Rawhide needing an update. Will
> Rawhide policy pull from upstream again before F11 release?
> 
> Not that upstream has merged my patch yet anyway...  

The updated policy has now been merged upstream, but the new interface was called milter_manage_spamass_state rather than milter_spamass_manage_state

(In reply to comment #18)
> Paul,
> 
> selinux-policy-2.4.6-224.el5.noarch.rpm
> 
> is out on http://people.redhat.com/dwalsh/RHEL5
> 
> Which has a totally untested milter policy on it, could you do a quick test?  

Doesn't seem to be there any more. Is there an SRPM I can look at too?

Well the newer version has the patch also.  SRPM of the latest policy should also be on http://people.redhat.com/dwalsh/RHEL5

(In reply to comment #20)
> Well the newer version has the patch also.  SRPM of the latest policy should
> also be on http://people.redhat.com/dwalsh/RHEL5  

There's no directory index there so I can't see the names of the files...

Oops

http://people.redhat.com/dwalsh/SELinux/RHEL5/

(In reply to comment #22)
> Oops
> 
> http://people.redhat.com/dwalsh/SELinux/RHEL5/  

I've had a look at selinux-policy-2.4.6-226.el5.src.rpm and it's missing the last round of updates:

milter.fc : context for /var/lib/spamass-milter

milter.te : declaration of spamass_milter_state_t and rules for /var/lib/spamass-milter

milter.if : interface milter_manage_spamass_state

spamassassin.te : milter_manage_spamass_state(spamc_t)
                  milter_manage_spamass_state(spamd_t)

Also, mta.te needs milter_getattr_all_sockets(system_mail_t) for newaliases run from the sendmail initscript.

Other than that it looks very much like what I'm running in production at $WORKPLACE.

Fixed in selinux-policy-2.4.6-228.el5

Not on your people page yet...

Your too quick for me.  Just finished building.  I will push it out today.

It is out there now.  I will also add your changes to F11 and F12

In milter.te, you have these rules duplicated in the milter-regex section as well as in the spamass-milter section:

# The milter runs from /var/lib/spamass-milter
files_search_var_lib(spamass_milter_t);
allow spamass_milter_t spamass_milter_state_t:dir search_dir_perms;

In spamassassin.te, still missing:

optional_policy(`
        milter_manage_spamass_state(spamc_t)
')

Also, since tools like razor aren't merged into spamc_t here (or are they?), I'd have though that there would have to be milter_manage_spamass_state(razor_t) etc. too? I don't use razor/pyzor myself so I'm not sure.

Noticed an error when updating:

# rpm -Fvh selinux-po*noarch.rpm
Preparing...                ########################################### [100%]
   1:selinux-policy         ########################################### [ 33%]
   2:selinux-policy-devel   ########################################### [ 67%]
Syntax error on line 1 ; [type=SEMI]
   3:selinux-policy-targeted########################################### [100%]
/sbin/restorecon reset /etc/cups/ppd context system_u:object_r:cupsd_etc_t:s0->system_u:object_r:cupsd_rw_etc_t:s0
/sbin/restorecon reset /etc/rc.d/init.d/autofs context system_u:object_r:initrc_exec_t:s0->system_u:object_r:automount_initrc_exec_t:s0
/sbin/restorecon reset /usr/sbin/rpc.rquotad context system_u:object_r:sbin_t:s0->system_u:object_r:rpcd_exec_t:s0
/sbin/restorecon reset /usr/sbin/spamass-milter context system_u:object_r:unlabeled_t:s0->system_u:object_r:spamass_milter_exec_t:s0
/sbin/restorecon reset /var/lib/spamass-milter context system_u:object_r:unlabeled_t:s0->system_u:object_r:spamass_milter_state_t:s0
/sbin/restorecon reset /var/lib/yum context system_u:object_r:var_lib_t:s0->system_u:object_r:rpm_var_lib_t:s0
/sbin/restorecon reset /var/run/spamass-milter context system_u:object_r:unlabeled_t:s0->system_u:object_r:spamass_milter_data_t:s0

I'm now running this policy on the firewall here that processes inbound mail, seems OK so far, no AVCs. The missing milter_manage_spamass_state(spamc_t) doesn't affect the configuration I'm using.

(In reply to comment #28)
> In milter.te, you have these rules duplicated in the milter-regex section as
> well as in the spamass-milter section:
> 
> # The milter runs from /var/lib/spamass-milter
> files_search_var_lib(spamass_milter_t);
> allow spamass_milter_t spamass_milter_state_t:dir search_dir_perms;
> 
> In spamassassin.te, still missing:
> 
> optional_policy(`
>         milter_manage_spamass_state(spamc_t)
> ')

These comments also apply to the F-11 and devel updates.

This bug has status "retest" om my bugzilla frontpage.
However, I have not seen that the last changes in comment #29 from Paul were added.
Hence, there does not seem to be anything for me to test.

I am not seeing the pyzor messages anymore.

Currently using:
selinux-policy-targeted-3.6.12-82.fc11.noarch
selinux-policy-3.6.12-82.fc11.noarch

Close issue?