Apache/PHP mail function SELinux permissions

Fri Nov 13 19:16:46 UTC 2009

On 11/13/2009 01:13 PM, Ted Rule wrote:
> 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.
> 
> 
> 
> 
Well not likely considering the about of code that is in apache.    The problem with running stuff within the apache process, you get all of the loadable apache modules which you do not know where they were created.

All calls would need to be fcntl(fd, F_SETFD, FD_CLOEXEC)