Trouble sending mail from PHP scripts

[Scott Gifford]

On Thu, Dec 30, 2010 at 3:55 AM, Dominick Grift <domg472 at gmail.com> wrote:

>
> On 12/30/2010 08:27 AM, Scott Gifford wrote:
>
> > 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.
>

I do want to allow them, so that errors and other output will end up
somewhere.

I'm having a hard time seeing how this process can be reasonably managed.
 It is probably impossible for me to predict in advance the types of all of
the things that could end up connected to the qmail-queue's filehandles.  A
message could be created in a temporary file and sent that way, or sent from
a pipe in a cronjob, etc.  Similarly its output could be sent to a temp
file, log file, etc.  There are hundreds of possible combinations that
should be allowed.  It seems that I would have to monitor the audit log,
carefully investigate exceptions, and modify the policy periodically.  But
this is very high-risk for mail, since a new combination of events that
triggers a new AVC denial and blocks the message could be some exceptional
event I want an email about, like smartd trying to send me a message saying
my hard drives are failing.

It seems like sendmail would have to deal with these same sorts of issues,
but I don't see anything in sendmail.if that seems to address them.

Is there some better way to manage this process or write policies that are a
bit more flexible, like a wildcard?  Or is some educated guesswork and
long-term monitoring of the AVC denials my only option?

Maybe it makes sense to run the mail server backend in unconfined_t?  That
seems risky in its own way.

[ ... ]

 > 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.
>

I may be able to find what I need in the AVC logs.  I think I'm just not yet
confident enough that my policies work as they should, and it would be
reassuring to see the domain transitions as they run.

I have had some problems with failed assertions, which have far too little
debug information to troubleshoot them with anything but guesswork, but
that's probably a separate issue.

[ ... ]

> I will try however to answer any specific questions you may have.
>

Thanks, I appreciate your help and your offer of more help in the future!
 :-)

-----Scott.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20101231/6da1d09e/attachment.html