| danwalsh ( @ 2008-04-05 11:18:00 |
Dear Oracle,
I would advise you that it is never a good idea to advise your customers to turn off a fundamental security software component of the operating system, so that your broken code can run.
http://download.oracle.com/docs/cd/B2835 9_01/relnotes.111/b32001/toc.htm
You have written PHP scripts that require the use of executable memory, a chief mechanism for crackers to attack systems. In order to have your PHP to work, you advise your customers to turn off SELinux enforcing mode, I guess this is better then tell customers to just shut it off all together.
If you investigated this at all you had two other options.
1. Fix your code, Read SELinux Memory Protection Tests , Uli has some good suggestions on how this can be done.
2. You could ship a policy package, which your customers could download to turn off the memory checking for apache while your coders fix their bugs, then only apache would be vulnerable, not the entire system. BTW You could generate the policy package by executing
# grep http /var/log/audit/audit.log | audit2allow -M oraclebufferoverflowallow
This will generate the oraclebufferoverflowallow.pp package. Which you can then ask your customers to download and install
semodule -i oraclebufferoverflowallow.pp
When you fix your bugs, they can execute
semodule -r oraclebufferoverflowallow
Your friend,
Dan
I would advise you that it is never a good idea to advise your customers to turn off a fundamental security software component of the operating system, so that your broken code can run.
http://download.oracle.com/docs/cd/B2835
You have written PHP scripts that require the use of executable memory, a chief mechanism for crackers to attack systems. In order to have your PHP to work, you advise your customers to turn off SELinux enforcing mode, I guess this is better then tell customers to just shut it off all together.
If you investigated this at all you had two other options.
1. Fix your code, Read SELinux Memory Protection Tests , Uli has some good suggestions on how this can be done.
2. You could ship a policy package, which your customers could download to turn off the memory checking for apache while your coders fix their bugs, then only apache would be vulnerable, not the entire system. BTW You could generate the policy package by executing
# grep http /var/log/audit/audit.log | audit2allow -M oraclebufferoverflowallow
This will generate the oraclebufferoverflowallow.pp package. Which you can then ask your customers to download and install
semodule -i oraclebufferoverflowallow.pp
When you fix your bugs, they can execute
semodule -r oraclebufferoverflowallow
Your friend,
Dan