-----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@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
- --
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
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-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
