Description of problem: I'm seeing the following denials running spamc via .procmailrc: type=AVC msg=audit(1242140267.499:464): avc: denied { read write } for pid=7236 comm="spamc" path="socket:[69191]" dev=sockfs ino=69191 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1242140267.499:464): avc: denied { read write } for pid=7236 comm="spamc" path="socket:[69193]" dev=sockfs ino=69193 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1242140267.499:464): avc: denied { read write } for pid=7236 comm="spamc" path="socket:[69195]" dev=sockfs ino=69195 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:system_r:sendmail_t:s0 tclass=tcp_socket probably leaked file descriptors? Doesn't appear to cause any problems. Version-Release number of selected component (if applicable): selinux-policy-2.4.6-229.el5 sendmail-8.13.8-2.el5 spamassassin-3.2.5-1.el5
THese are a leaked file descriptor caused I believe by nss_ldap.
I think there's a decent chance that this is the same bug as #512856.
Is there an updated nss_ldap for EL5 I can test with?
Created attachment 449470 [details] test package
I've built and installed it, but still seeing these messsages. Restarted sendmail, nscd, and sshd for grins but still seeing: type=AVC msg=audit(1285356600.905:4285): avc: denied { write } for pid=32535 comm="spamc" path="pipe:[624117]" dev=pipefs ino=624117 scontext=root:system_r:spamc_t:s0 tcontext=root:system_r:sendmail_t:s0 tclass=fifo_file type=AVC msg=audit(1285356600.905:4285): avc: denied { read write } for pid=32535 comm="spamc" path="socket:[624068]" dev=sockfs ino=624068 scontext=root:system_r:spamc_t:s0 tcontext=root:system_r:sendmail_t:s0 tclass=unix_stream_socket type=AVC msg=audit(1285356600.905:4285): avc: denied { read write } for pid=32535 comm="spamc" path="socket:[624070]" dev=sockfs ino=624070 scontext=root:system_r:spamc_t:s0 tcontext=root:system_r:sendmail_t:s0 tclass=unix_stream_socket
It's the tcp_socket leak (the connection to the directory server) we're fixing here; I'm not sure these others are under nss_ldap's control -- they look like a problem with letting sendmail run procmail run spamc. CCing dwalsh.
Yes these are either leaks or normal fifo_file passing of stdin,stdout,stderr between multiple entities. In F14/RHEL6 policy we have these rules. audit2allow -i /tmp/t #============= spamc_t ============== #!!!! This avc is allowed in the current policy allow spamc_t sendmail_t:fifo_file write; #!!!! This avc has a dontaudit rule in the current policy allow spamc_t sendmail_t:unix_stream_socket { read write }; Open a bug on RHEL5 for this policy to be backported.
(In reply to comment #10) > Open a bug on RHEL5 for this policy to be backported. Opened bug #637843.
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 therefore 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-2011-0097.html