I've had a "problem" recently with SELinux permissions related to PHP's mail functions. These appear to give rise to two different classes of error, one for read permissions on the httpd_t domain itself, and one for read/write permission on a file in the httpd_tmp_t domain. aureport gives this: $ sudo aureport -a |grep system_mail |head 6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116101 7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116102 17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116124 23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116136 24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116136 30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116148 31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116148 39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116168 40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file read user_u:system_r:httpd_t:s0 denied 116168 48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file read write user_u:object_r:httpd_tmp_t:s0 denied 116181 Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5 Looking in more detail at ausearch we see that the httpd_t related avc is apparently related to an "eventpoll" file descriptor, whilst the httpd_tmp_t avc is probably for a file created by php in /tmp. Looking at the php source code itself, I see that it is simply opening a temporary file containing the body of the Email and pouring it via a pipe into an instance of sendmail via popen(). As such, it seems likely that both classes of avc's are simply file descriptors "leaking" into the popen'ed child process running in the system_mail_t domain. Sadly, for other reasons, the Apache hosts are still in permissive, so it's currently unclear to me whether the PHP mail function would fail completely if either of these permissions are denied in enforcing mode, but it makes me wonder whether there would be any sense in a wider solution to leaky descriptors which caused popen() itself to close all file descriptors other than STDIN/STDOUT/STDERR if the popen'ed executable implies a domain transition. Alternatively, one might envisage a set of selinux booleans which allowed a more granular control of leaked descriptors outside of STDIN/STDOUT/STDERR. The other potential policy improvement would be for system_mail_t to simply "dontaudit" denials relating to eventpoll class file descriptors and temporary files in context *_tmp_t. time->Sun Oct 25 13:12:48 2009 type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11 success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0 ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs ino=129640960 scontext=user_u:system_r:system _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file ---- time->Sun Oct 25 13:15:57 2009 type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11 success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0 ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256476557.234:116102): avc: denied { read write } for pid=22099 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Sun Oct 25 13:39:46 2009 type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11 success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0 ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256477986.012:116124): avc: denied { read write } for pid=23560 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Sun Oct 25 13:43:04 2009 type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11 success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0 ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs ino=129701955 scontext=user_u:system_r:system _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file type=AVC msg=audit(1256478184.954:116136): avc: denied { read write } for pid=23802 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ---- time->Sun Oct 25 13:52:57 2009 type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11 success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0 ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid= 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=user_u:system_r:system_mail_t:s0 key=(null) type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs ino=129734033 scontext=user_u:system_r:system _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file type=AVC msg=audit(1256478777.377:116148): avc: denied { read write } for pid=24439 comm="sendmail" path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file ----

On Fri, 2009-11-13 at 10:29 -0500, Daniel J Walsh wrote: > On 11/13/2009 09:53 AM, Ted Rule wrote: >> >> I've had a "problem" recently with SELinux permissions related to PHP's >> mail functions. These appear to give rise to two different classes of error, >> one for read permissions on the httpd_t domain itself, and one for >> read/write permission on a file in the httpd_tmp_t domain. >> >> aureport gives this: >> >> $ sudo aureport -a |grep system_mail |head >> 6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file >> read user_u:system_r:httpd_t:s0 denied 116101 >> 7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file >> read write user_u:object_r:httpd_tmp_t:s0 denied 116102 >> 17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file >> read write user_u:object_r:httpd_tmp_t:s0 denied 116124 >> 23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file >> read write user_u:object_r:httpd_tmp_t:s0 denied 116136 >> 24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file >> read user_u:system_r:httpd_t:s0 denied 116136 >> 30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file >> read write user_u:object_r:httpd_tmp_t:s0 denied 116148 >> 31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file >> read user_u:system_r:httpd_t:s0 denied 116148 >> 39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file >> read write user_u:object_r:httpd_tmp_t:s0 denied 116168 >> 40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file >> read user_u:system_r:httpd_t:s0 denied 116168 >> 48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file >> read write user_u:object_r:httpd_tmp_t:s0 denied 116181 >> >> Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5 >> >> Looking in more detail at ausearch we see that the httpd_t related avc >> is apparently related to an "eventpoll" file descriptor, whilst the >> httpd_tmp_t >> avc is probably for a file created by php in /tmp. >> >> Looking at the php source code itself, I see that it is simply opening a >> temporary file containing the body of the Email and pouring it via a >> pipe into an instance of sendmail via popen(). >> >> As such, it seems likely that both classes of avc's are simply file >> descriptors "leaking" into the popen'ed child process running in the >> system_mail_t domain. >> >> Sadly, for other reasons, the Apache hosts are still in permissive, so >> it's currently unclear to me whether the PHP mail function would fail >> completely if either >> of these permissions are denied in enforcing mode, but it makes me >> wonder whether there would be any sense in a wider solution to leaky >> descriptors which caused popen() itself to close all file descriptors >> other than STDIN/STDOUT/STDERR if the popen'ed executable implies a >> domain transition. Alternatively, one might envisage a set of selinux >> booleans which allowed a more granular control of leaked descriptors >> outside of STDIN/STDOUT/STDERR. >> >> >> The other potential policy improvement would be for system_mail_t to >> simply "dontaudit" denials relating to eventpoll class file descriptors >> and temporary files in context *_tmp_t. >> >> >> >> >> time->Sun Oct 25 13:12:48 2009 >> type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11 >> success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0 >> ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid= >> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >> subj=user_u:system_r:system_mail_t:s0 key=(null) >> type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for >> pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs >> ino=129640960 scontext=user_u:system_r:system >> _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file >> ---- >> time->Sun Oct 25 13:15:57 2009 >> type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11 >> success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0 >> ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid= >> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >> subj=user_u:system_r:system_mail_t:s0 key=(null) >> type=AVC msg=audit(1256476557.234:116102): avc: denied { read write } >> for pid=22099 comm="sendmail" >> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >> ---- >> time->Sun Oct 25 13:39:46 2009 >> type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11 >> success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0 >> ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid= >> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >> subj=user_u:system_r:system_mail_t:s0 key=(null) >> type=AVC msg=audit(1256477986.012:116124): avc: denied { read write } >> for pid=23560 comm="sendmail" >> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >> ---- >> time->Sun Oct 25 13:43:04 2009 >> type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11 >> success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0 >> ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid= >> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >> subj=user_u:system_r:system_mail_t:s0 key=(null) >> type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for >> pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs >> ino=129701955 scontext=user_u:system_r:system >> _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file >> type=AVC msg=audit(1256478184.954:116136): avc: denied { read write } >> for pid=23802 comm="sendmail" >> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >> ---- >> time->Sun Oct 25 13:52:57 2009 >> type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11 >> success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0 >> ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid= >> 48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966 >> comm="sendmail" exe="/usr/sbin/sendmail.sendmail" >> subj=user_u:system_r:system_mail_t:s0 key=(null) >> type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for >> pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs >> ino=129734033 scontext=user_u:system_r:system >> _mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file >> type=AVC msg=audit(1256478777.377:116148): avc: denied { read write } >> for pid=24439 comm="sendmail" >> path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746 >> 56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0 >> tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file >> ---- >> >> >> > Is mail working? IE Is the mail being sent? These look like leaked file descriptors. Mail from Apache/PHP is working, but as I mentioned, the server is in permissive mode, so I can't tell whether it would stop working were we to move to enforcing. Whilst I could add some custom rules to work round this if need be, my more general thought was whether a cleaner overall solution to leaked descriptors via popen() might be possible.

In the course of trying to get a syslog-ng daemon running on a non-standard TCP port on CentOS5, I came across an AVC for the port which appeared to already have a permission in the SELinux Policy. We tried to make syslog-ng listen on TCP Port 5514, and as a result we got the following set of audit messages: $ sudo ausearch -ts yesterday -c syslog-ng ---- time->Fri Jul 9 23:04:26 2010 type=SYSCALL msg=audit(1278713066.242:269066): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfb34210 a2=95b51e8 a3=6 items=0 ppid=1 pid=1713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="syslog-ng" exe="/sbin/syslog-ng" subj=system_u:system_r:syslogd_t:s0 key=(null) type=AVC msg=audit(1278713066.242:269066): avc: denied { name_bind } for pid=1713 comm="syslog-ng" src=5514 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket ---- time->Fri Jul 9 23:04:26 2010 type=ANOM_ABEND msg=audit(1278713066.291:269067): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:syslogd_t:s0 pid=1713 comm="syslog-ng" sig=11 ---- time->Fri Jul 9 23:27:59 2010 type=SYSCALL msg=audit(1278714479.797:269169): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bffe96d0 a2=97a6928 a3=6 items=0 ppid=1 pid=15354 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=44818 comm="syslog-ng" exe="/sbin/syslog-ng" subj=user_u:system_r:syslogd_t:s0 key=(null) type=AVC msg=audit(1278714479.797:269169): avc: denied { name_bind } for pid=15354 comm="syslog-ng" src=5514 scontext=user_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket ---- time->Fri Jul 9 23:27:59 2010 type=ANOM_ABEND msg=audit(1278714479.833:269170): auid=500 uid=0 gid=0 ses=44818 subj=user_u:system_r:syslogd_t:s0 pid=15354 comm="syslog-ng" sig=11 $ However, despite the fact that the AVC suggested that we needed to add the permission: allow syslogd_t port_t : tcp_socket { name_bind name_connect }; an sesearch suggests that the permission already exists: $ sudo sesearch --allow -s syslogd_t | grep tcp |grep name.bind allow syslogd_t rsh_port_t : tcp_socket { name_bind name_connect }; allow syslogd_t syslogd_port_t : tcp_socket { name_bind name_connect }; allow syslogd_t port_t : tcp_socket { name_bind name_connect }; allow syslogd_t reserved_port_t : tcp_socket { name_bind name_connect }; $

Eventually, we repaired the situation by adding TCP/5514 as a syslogd_port_t, as in: $ sudo semanage port -l |grep 514 cluster_port_t tcp 5149, 40040, 50006, 50007, 50008 cluster_port_t udp 5149, 50006, 50007, 50008 rsh_port_t tcp 514 syslogd_port_t tcp 5514 syslogd_port_t udp 514 virt_port_t tcp 16509, 16514 virt_port_t udp 16509, 16514 $

But my curiousity is piqued. Why did the policy deny the binding to a type port_t, when the policy appeared to already allow this? FWIW, the policy at the moment is a somewhat aged: selinux-policy-targeted-2.4.6-203.el5

-- Ted Rule Director, Layer3 Systems Ltd http://www.layer3.co.uk/ -- selinux mailing list selinux(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux