grsecurity forums

Hello!

I recently upgraded to the 2.6.23.12 kernel with the grsec patch and presumably since then I am experiencing a problem: the PHP Zend Optimizer does not work, at all.
In the apache error.log I get tons of these:

Code: Select all

Failed loading /usr/lib/php5/ioncube_loader_lin_5.2.so:  /usr/lib/php5/ioncube_loader_lin_5.2.so: cannot enable executable stack as shared object requires: Permission denied
Failed loading /usr/local/Zend/lib/ZendExtensionManager.so:  /usr/local/Zend/lib/ZendExtensionManager.so: cannot enable executable stack as shared object requires: Permission denied

I don't really know how to interpret this. I didn't change the PHP config at all, only a security php update was made via debian security. Grsec itself does not log anything significant concerning this issue.
If I leave Zend enabled in php.ini, Apache will eventually die completelly (gets a SIGTERM).

The distro is Debian 4.0 with all updates of course. Anyone has this problem? Could it be related to grsec, ar am i wrong here?

Thanks
Hal

I remember i came out to something like this weeks ago and it was selinux the cause of the issue, may be check selinux logs or disable it and retry !

Hello!

Hal9000 wrote:
I recently upgraded to the 2.6.23.12 kernel with the grsec patch and presumably since then I am experiencing a problem: the PHP Zend Optimizer does not work, at all.
In the apache error.log I get tons of these:

Code: Select all

Failed loading /usr/lib/php5/ioncube_loader_lin_5.2.so:  /usr/lib/php5/ioncube_loader_lin_5.2.so: cannot enable executable stack as shared object requires: Permission denied
Failed loading /usr/local/Zend/lib/ZendExtensionManager.so:  /usr/local/Zend/lib/ZendExtensionManager.so: cannot enable executable stack as shared object requires: Permission denied


I don't really know how to interpret this.

The dynamic linker (/lib/ld-linux*.so) tried to make the stack executable for
the library (/usr/lib/php5/ioncube_loader_lin_5.2.so) because of PT_GNU_STACK RWX
marking. The attempt was denied by rejected by PaX (as it should be). For some
stupid reason the linker treats this failure as a fatal.

Hal9000 wrote:I didn't change the PHP config at all, only a security php
update was made via debian security.

I doubt Debian packages install anything into /usr/local.

Hal9000 wrote:Grsec itself does not log anything significant concerning this issue.

Reporting every "permission denied" will flood your logs in a moment.

Hal9000 wrote:The distro is Debian 4.0 with all updates of course.
Anyone has this problem?

Not exactly this problem, but a lots of similar ones. See e.g.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323944

Hal9000 wrote:Could it be related to grsec, or am i wrong here?

Let's put it another way: grsec exhibits bugs/design errors of the library
in question.

m0dY wrote:I remember i came out to something like this weeks ago and it was
selinux the cause of the issue

SELinux, like any sane security system, bans self-modifying code.
So does PaX/grsec. Of course, you can (selectively) switch off this
restriction. But that makes patching the kernel kind of pointless -- you
are not going to use the protection grsec provides, so why bother, just
use vanilla kernel, and that's it.

m0dY wrote:may be check selinux logs or disable it and retry!

Don't take me wrong, but this advice is irrelevant, because OP runs grsec,
thus, he already has selinux disabled (in the kernel config). And in fact
your advice is harmul, because it's really wrong to switch off the protection
instead of fixing the buggy software.

Yeah, of course SElinux is disabled here
I remember that on late December I upgraded Debian to 4.0r2, which also included an updated libc6 library. Maybe that update is the cause of harm?
hal

Hal9000 wrote:I remember that on late December I upgraded Debian to 4.0r2, which also included an updated libc6 library. Maybe that update is the cause of harm?

the forum has a search feature that would have given you the answer if you had searched for your error message, except spender's board upgrade screwed it up apparently, so your next stop is google and you'll see that we discussed/explained/solved this a few times in the past already.

PaX Team wrote:you'll see that we discussed/explained/solved this a few times in the past already.

That "optimizer" thing sounds a bit suspicious. The library might be some kind of
JIT compiler, so, it might *actually* need to execute code on the stack to operate
properly.

Hal9000 wrote:I remember that on late December I upgraded Debian to 4.0r2, which
also included an updated libc6 library. Maybe that update is the cause
of harm?
hal

I doubt it. However, it might expose bugs in other libraries.