| So does SELInux really stop any attacks? |
[Apr. 5th, 2008|07:08 am] |
Tresys corporation is tracking some of the known vulnerabilities in the past that SELinux has thwarted.
You can read about them at
http://tresys.com/selinux/
One key feature of SELinux is the confinement of executable memory. This tops applications from having memory that is both executable and writable at the same time. A lot of attacks on computer software involve a coding mistake in code that allows the writing of memory beyond the end of an allocated buffer, called a buffer overflow. So a cracker find a piece of code that allocates less space then the code can write. The cracker tricks the application to writing his data into the overflowed buffer. Finally he attempts to get the application to execute the buffer that he has just written. SELinux executable memory checks in the kernel prevent this.
While we have attempted to turn these checks on for the unconfined user in the past, we have had missed success, because of badly written applications breaking. But for almost all confined applications these checks are turned on. So if a vulnerability exists in a confined application that involves a buffer overflow, most likely SELinux will prevent it.
|
|
|
| Dear Oracle, |
[Apr. 5th, 2008|11:18 am] |
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/B28359_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 |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
danwalsh's journal