Trouble sending mail from PHP scripts

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/30/2010 03:55 AM, Dominick Grift wrote:
> On 12/30/2010 08:27 AM, Scott Gifford wrote:
>> Hello,
> 
>> I'm having some trouble with an SELinux policy to allow sending mail from a
>> PHP script run from our Web server with a local installation of qmail on a
>> CentOS 5 system.  We send mail using php's mail() function, which calls
>> /usr/bin/sendmail, which in turn calls /var/qmail/bin/qmail-inject, then
>> /var/qmail/bin/qmail-queue, which actually puts the message in the queue.
> 
>> SELinux comes with some default qmail policies, but out-of-the-box we had
>> AVC denials when qmail-queue would try to write the message into the queue,
>> since the Web script context was not permitted to do this.
> 
>> I decided to take this opportunity to learn about writing SELinux policies.
>>  I know qmail very well, so thought I would write a policy for qmail.  The
>> policy would transition to a new type mail_qmail_queue_t when qmail-queue
>> was run, and then allow this type to write into the queue.
> 
>> I think I have the basics working, but I'm running into some snags, and I
>> don't have enough experience to know what sorts of solutions are likely to
>> work out.
> 
>> First, I am seeing some denials that seem to be related to file descriptors
>> passed by Apache to qmail-queue.  When qmail-queue is run, stderr is
>> connected to the Web server log, and stdout is connected to the HTTP socket.
>>  This is a pretty normal setup, which will cause any output to show up in
>> the user's browser and errors to show up in the Web server log.  However I
>> get these AVC denials:
> 
>>    - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
>>     denied  { read } for  pid=9643 comm="qmail-queue" path="pipe:[4937510]"
>>    dev=pipefs ino=4937510 scontext=system_u:system_r:mail_qmail_queue_t:s0
>>    tcontext=system_u:system_r:httpd_t:s0 tclass=fifo_file
>>    - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
>>     denied  { append } for  pid=9643 comm="qmail-queue"
>>    path="/var/log/httpd/error_log" dev=md2 ino=24183170
>>    scontext=system_u:system_r:mail_qmail_queue_t:s0
>>    tcontext=user_u:object_r:httpd_log_t:s0 tclass=file
>>    - Thu Dec 30 01:27:47 2010 type=AVC msg=audit(1293690467.534:90936): avc:
>>     denied  { read write } for  pid=9643 comm="qmail-queue"
>>    path="socket:[13964]" dev=sockfs ino=13964
>>    scontext=system_u:system_r:mail_qmail_queue_t:s0
>>    tcontext=system_u:system_r:httpd_t:s0 tclass=tcp_socket
> 
>> I could write policy to allow mail_qmail_queue access to these httpd_t
>> resources, but in general it should not have that access; only when it is
>> run from Apache.  I could create a special type for "qmail-queue run from
>> Apache", but that quickly gets out-of-hand if I create custom policies for
>> each program that sends mail.  What is the normal way to deal with these
>> sorts of situations?
> 
> You can silently deny access vectors. So if you know that denying this
> access does not cause any loss in functionality then consider silently
> denying some of this.
> 
> Anything else, i guess,  will just have to be allowed.
> 
In RHEL6 you can allow this via inheritence.  IE Deny the open rule.  So
you tool could append to the httpd_log_t but not open it.
>> Second, I am having some trouble getting file contexts set up.  I have
>> several qmail installations with different policies, so I wrote a rule in my
>> fc file like this:
> 
>> /var/qmail(-.*)?/bin/qmail-queue --
>> gen_context(system_u:object_r:mail_qmail_queue_exec_t,s0)
> 
> 
>> When I use that rule, qmail-queue gets labeled bin_t, I think because of
>> another rule saying anything in a directory named "bin" is "bin_t".  How can
>> I tell it my rule is more specific or higher priority than the default rule?
>>  For that matter, how can I figure out what rule is overriding mine?
> 
> This is a similar el5 issue i encountered just yesterday and upto now i
> havent found the cause and solution to the issue, other then setting the
> file context manually with the chcon command.
> 
The rules for file context come down to specifity.  I would search for
rules about /var.*bin_t And see which rule is being matched.  one trick
is that if your rule is longer it will get chosen.

On F15 I see

grep /var.*bin_t /etc/selinux/targeted/contexts/files/file_contexts
/var/ftp/bin(/.*)?	system_u:object_r:bin_t:s0
/var/qmail/bin(/.*)?	system_u:object_r:bin_t:s0
/var/mailman/bin(/.*)?	system_u:object_r:bin_t:s0
/var/lib/asterisk/agi-bin(/.*)?	system_u:object_r:bin_t:s0
/var/qmail/rc	--	system_u:object_r:bin_t:s0
/var/qmail/bin	-d	system_u:object_r:bin_t:s0


Not sure what you have on RHEL5.

> 
>> Third, is there a useful guide for troubleshooting SELinux policy execution?
>>  When things don't work as I expect them to, it's hard to find the reason if
>> it's not obvious from the audit.log.
> 
> Examples?
> 
> It usually boils down to analyzing AVC denials.
> 
> 
>> Finally, can anybody recommend a good book or other resource for learning
>> SELinux?  I have *SELinux by Example*, but it seems that conventions for
>> policy files have changed a great deal since it was written.
> 
> Me and another guy had started to write a document about just that but
> it just did not take off unfortunately, and now i am no longer sure if i
> will have time for it in the future for it due to other responsibilities.
> 
> So i cannot recommend anything other then selinyxbyexample and the
> actual reference policy source policy.
> 
> I will try however to answer any specific questions you may have.
> 
>> Thanks!
> 
>> -----Scott.
> 
> 


> 
> 
>> --
>> selinux mailing list
>> selinux at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
- --
selinux mailing list
selinux at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0iSy0ACgkQrlYvE4MpobO9+wCfUnItW/A3sjAkgppuvkbbBUAv
WOsAoIoGgsUl5t0LtvXK/6OBOOj6+eSo
=m5ie
-----END PGP SIGNATURE-----