Description of problem: selinux prevents procmail from running spamc. Running in permissive mode to get all denials: type=AVC msg=audit(1202342416.006:25876): avc: denied { execute } for pid=1948 comm="procmail" name="spamc" dev=dm-4 ino=161168 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file type=AVC msg=audit(1202342416.006:25876): avc: denied { execute_no_trans } for pid=1948 comm="procmail" path="/usr/bin/spamc" dev=dm-4 ino=161168 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file type=AVC msg=audit(1202342416.006:25876): avc: denied { read } for pid=1948 comm="procmail" path="/usr/bin/spamc" dev=dm-4 ino=161168 scontext=user_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file Version-Release number of selected component (if applicable): selinux-policy-2.4.6-119.el5
This is new with -119.
procmail has never been able to run spamc? It is not able to in Rawhide either? It can run /usr/bin/spamassassin But not /usr/bin/spamc If it needs to I can add the policy.
I just started seeing these messages when I applied 2.4.6-119.el5. Before that it ran fine. Procmail definitely needs to be able to run spamc - that's how you run spamassassin in client/server mode.
optional_policy(` corenet_udp_bind_generic_port(procmail_t) corenet_dontaudit_udp_bind_all_ports(procmail_t) spamassassin_manage_user_home_files(procmail_t) spamassassin_exec(procmail_t) spamassassin_exec_client(procmail_t) spamassassin_read_lib_files(procmail_t) ') THis is still in policy.
Somehow it's not making it in though. I did a: chcon -t spamassassin_exec_t /usr/bin/spamc to make it look like /usr/bin/spamassassin and I still get denials. Any way to decompile the current policy to see what's in place?
sesearch --allow | grep procmail_t | grep spamc_exec_t
[root@coop00 ~]# rpm -q selinux-policy selinux-policy-2.4.6-30.el5 [root@coop00 ~]# sesearch --allow | grep procmail_t | grep spamc_exec_t allow procmail_t spamc_exec_t : file { ioctl read getattr lock execute execute_no_trans }; Install -120. [root@coop00 ~]# rpm -q selinux-policy selinux-policy-2.4.6-120.el5 [root@coop00 ~]# sesearch --allow | grep procmail_t | grep spamc_exec_t [root@coop00 ~]#
Could you get this info seinfo -t | grep spam seinfo -t | grep razor
[root@earth files]# seinfo -t | grep spam Rule loading disabled spamd_var_lib_t spamd_var_run_t spamd_spool_t spamd_server_packet_t spamassassin_exec_t spamc_exec_t spamd_exec_t spamd_client_packet_t spamd_t spamd_tmp_t spamd_port_t [root@earth files]# seinfo -t | grep razor Rule loading disabled razor_var_lib_t razor_client_packet_t razor_exec_t razor_etc_t razor_log_t razor_port_t razor_server_packet_t razor_t
Try 121, on people.
Looks good: # sesearch --allow | grep procmail_t | grep spamc_exec_t allow procmail_t spamc_exec_t : file { ioctl read getattr lock execute execute_no_trans }; and procmail runs spamc without trouble now. What was up?
optional_policy(`') block was added that tried to check if a the allow spamd to write to homedir boolean was set. I back ported some code from rawhide, that was causing this block to not add the rules. optional_policy says that if a type in a gen_requires block does not exist, don't add any of the rules. So the back ported section contained user_razor_home_t which was causing the entire block to be removed. fixed in selinux-policy-2.4.6-121.el5
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0465.html