One problem though is that the application does not install well in an SELinux environment.
In Red Hat Enterprise Linux 5 we have added protection to the operating system to block the "execution" of "writable" memory. This is one of the major ways crackers are able to take advantage of badly written code. They find a buffer overflow in a piece of code and then overwrite the memory, finally the cracker tricks the application to start executing the memory buffer they just overwrote. SELinux can prevent the executing of writable memory with the execmod, execheap, execstack and execmem checks, even for unconfined processes.
One problem with this, lots of code is poorly written or built and asks for these permissions even when the programs do not need them. SELinux provides 4 booleans that can turn off these checks for unconfined processes.
- allow_execmem and allow_execstack which are turned on by default.
allow_execstack and allow_execmem should be turned off, if you can.
# setsebool -P allow_execstack=0allow_execmem=0.
Certain applications java and mono need the these privs in order to run properly. So any java or mono application, needs to have policy written for them or be labeled java_exec_t or mono_exec_t and they will work properly with the booleans turned off. wine also requires these permissions since it executes Windows code, wine should be labeled wine_exec_t. Finally if you find an application that requires execmem or execstack you can label it unconfined_execmem_exec_t and it will run with the booleans turned off.
- allow_execheap which are turned off by default.
We have not seen too many instances where code needed allow_execheap turned on, and since this is considered very bad, we turn it off.
- allow_execmod which is turned on by default
After Symphony was released I was told people were having a hard time installing it on RHEL5 boxes with SELinux in enforcing mode, So this is the steps I took to install Symphony with SELinux on RHEL5.execmod usually affects shared libraries. There are so many badly built libraries that we have a special label for them, to allow applications to run. textrel_shlib_t. This label tells the kernel to allow the library execmod. There are many files on the system that are labeled textrel_shlib_t and we are trying to find them and get the providers to fix them.
- Download package from http://symphony.lotus.com/software/lotus/s
- Execute the exectractor binary
- # ./IBM_Lotus_Symphony_Linux.bin
- cd IBM_Lotus_Symphony_Linux
- Execute the setup program
- # ./setup.bin
- It blows up, with an error No Java Runtime Environment (JRE) was found on this system.
- Run "audit2allow -a" to see if SELinux is the culprit.
- It shows allow unconfined_t tmp_t:file execmod
- Since setup.bin is extracting the shared libraries, I can not label it textrel_shlib_t
- Temporarily turn off execmod protection for unconfined domains
- # setsebool allow_execmod 1
- Execute the setup program
- .# /setup.bin
- Take all defaults
- setup completes successfully and program runs, but allow_execmod is still turned on.
- I want to fix the context on the newly installed files in /opt. Most of the shared libraries are built incorrectly. SoI setup the default context of these libraries to allow text reloaction, by setting their context to textrel_shlib_t.
- # semanage fcontext -a -t textrel_shlib_t "/opt/ibm/lotus/Symphony/.*\.so"
- # restorecon -R -v /opt/ibm
- Turn the allow_execmod boolean off
- # setsebool allow_execmod 0
- Symphony now works fine on RHEL5.
- Now I have to open a bug report for Symphony to fix their damn libraries :^)
Ulrich Drepper further explains the SELinux Memory Protection Tests