Apache/PHP mail function SELinux permissions

Ted Rule ejtr at layer3.co.uk
Fri Nov 13 18:13:54 UTC 2009


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.




-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/




More information about the fedora-selinux-list mailing list