Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

[George Machitidze <giomac () gmail com>]

Heh

disable_functions and open_basedir is bad example. It's not an apache
part - it's PHP, so forget about it - <it's a feature of PHP>.
enable_functions is a very bad idea - the list of allowed ones would
be too large for any business, development or user needs. That's why
administrators (I do) read changelogs before upgrading software, and
why they check all the functions documented and all the details
regarding what these functions do, this is PHP feature, not httpd
feature or httpd bug. The question is why PHP processes, forks etc
running under apache/cgi/etc are allowed to do anything what apache
can do. This is the issue right? If PHP has security a bug, which
allows to bypass these php.ini-related security/sandboxing settings,
it means we should sacrifice security needs and trust PHP only? I need
them both, where possible. We can't even control and isolate
subprocesses with selinux, because for cgroups/selinux they share same
group and contexts. BTW, one reminded me in here - itk mpm has
workarounds for this problem. http://mitka.us/articles/mpm-itk/
It's definitely not a bug, it's an architecture, which must be
redesigned sooner or later.

On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor <coderaptor () gmail com> wrote:
> disable_functions


Best regards,
George Machitidze