[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HOWTO: qmail's sendmail, SELinux, and apache/php
Joshua,
You are right about "httpd_sys_content_t" not being the ideal context and
the security risks it poses. I just needed to get it to work. I have
posted this issue to a SELinux mailing list. Once I get feedback from the
SELinux experts I'll repost my HOW-TO.
In hindsight, I shouldn't have posted my HOW-TO just yet.
-----Original Message-----
From: Joshua Nichols [mailto:jnichols@xxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, May 08, 2008 8:09 AM
To: qmail@xxxxxxxxxxxxx
Subject: Re: HOWTO: qmail's sendmail, SELinux, and apache/php
On May 7, 2008, at 11:44 PM, D. Hilbig wrote:
> With SELinux enabled, apache/php cannot use qmail's sendmail because
> of
> context restrictions.
Hadn't run into this personally yet, thanks for the heads up.
> # chcon -t httpd_sys_content_t /var/qmail/bin/sendmail
> allows apache/php to invoke qmail's sendmail
I certainly haven't tested this, so I don't mean to contradict you,
but isn't "httpd_sys_content_t" the context for html and php pages?
Since the default SELinux policies of CentOS 5 /do/ work with
sendmail, wouldn't a more logical approach be to apply the standard
sendmail contexts to the binaries? For CentOS, /usr/sbin/sendmail has
the "user_u:object_r:sbin_t" context. I'm concerned about the
security implications of the qmail binaries being treated as html
content--I'm well aware of the security of the qmail binaries
themselves, but I can conceive of an apache vector that may allow
qmail-inject to be exploited or modified if the contexts are set as
such.
Perhaps if the community could come to a consensus about the "correct"
contexts to use, Dave would consider adding some chcon lines to LWQ.
Another approach could be that netqmail 1.07 could patch the build
scripts to set context as well as permissions (assuming SELinux is
present and enabled).
I suspect within a few years SELinux will become another errno debate,
but eventually setting contexts appropriately will be a requirement
for many users.
--joshua.