grsec: denied marking stack executable as requested by PT_GNU_STACK marking

Examples:

kernel: grsec: denied marking stack executable as requested by PT_GNU_STACK marking in /opt/dell/invcol.rBSW9tuFOE/Tape_IBM/libibmltodup.so.1.0.0 by /opt/dell/invcol.rBSW9tuFOE/Tape_IBM/IbmDup[IbmDup:6177] uid/euid:0/0 gid/egid:0/0, parent /opt/dell/invcol.rBSW9tuFOE/invcol[invcol:5038] uid/euid:0/0 gid/egid:0/0

error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied

grsec: From 1.2.3.4: denied marking stack executable as requested by PT_GNU_STACK marking in /usr/NX/lib/libnxcim.so by /usr/NX/bin/nxserver.bin[nxserver.bin:4626] uid/euid:495/495 gid/egid:10038/10038, parent /usr/sbin/sshd[sshd:4622] uid/euid:495/495 gid/egid:10038/10038

Discussion

This means that you have an application installed with a serious vulnerability. The Secure ASL kernel is preventing this application from opening a hole in your system.

Some application developers may configured their applications insecure to use what is referred to as an "executable stack". An executable stack allows an attacker to inject raw code into your system, bypassing your operating systems entire security model. This is a well known and widely used method of compromising systems completely.

Configuring an application in this manner dangerously opens your system to full compromise. Very few, if any applications actually require this insecure state to operate, and often times configuring applications in this manner is done by the application developer in error. You can reconfigure these applications to not do this by following the process below.

The ASL kernel protects you from this dangerous mistake by not allowing these applications to configure your system into this extremely insecure condition.

There are three options for dealing with this critical vulnerability, from most secure to least secure:

Option 1: (Most secure option)

ASL will not allow these applications to punch holes in your system, and running the command below will remove that label from the application so it will run properly and securely.

 execstack -c /path/to/application

Sometimes vendors will do this to the libraries the application uses, and not the binary calling it. If you see a log message with a ".so" in it, that indicates a library has been insecurely configured by your vendor. Here is an example:

'error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied'

In which case you may have to remove this vulnerablity from the library itself. You can do this by using the "execstack" comannd and the "-c" switch, which stands for "clear". This command will remove the setting, or clear it, from the application that is causing this critical vulnerability. For example:

 execstack -c  /opt/splunk/lib/libcrypto.so.0.9.8

If you aren't sure which binary or library has the stack execute bit set, you can run this command to query the file:

 execstack -q /opt/splunk/lib/libcrypto.so.0.9.8

If you see this:

 - /lib/libcrypto.so.0.9.8e

The "-" means that file is safe, and does not have the stack execute bit set, in which case the binary calling the library is the likely culprit and you would want to query that file and remove the flag from it.

If you see this:

 X /opt/splunk/lib/libcrypto.so.0.9.8

The X means stack execution is allowed, which also means X marks the spot for attacking your stack - which ASL will not allow. To close the vulnerability in the above example, remove the stack execute flag from the library by running this command as root:

 execstack -c /opt/splunk/lib/libcrypto.so.0.9.8

We also recommend you contact your application vendor and ask them to remove these flags from their applications. They are not necessary with modern Linux kernels, and are bad and unsafe practices which will expose your system to compromise if you are not running ASL. If you are running ASL, you will need to reconfigure these applications per the instructions here.

Option 2:

Some applications require this vulnerable condition during installation. If you are unfortunate enough to have one of those applications, and the application vendor is not willing to fix their application, reboot the system into a non-secure kernel (a non ASL kernel) and install your application. Then reboot the system into the ASL kernel and follow the instructions in Option 1 to fix the vulnerable applications.

Option 3: (Insecure option)

We do not recommend you use this option.

It is possible to disable all stack protection in the ASL kernel so that it will not be enforced by default and only on executables marked explicitly. No executables are marked in this manner by ASL by default, as by default ASL automatically protects all executables. If you wish to use this option you will need to mark the executables you wish to protect.

Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various kernel protection features at runtime via the entries in /proc/sys/kernel/pax.