James Morris - SELinux memory protections are your friend
SELinux memory protections are your friend|
I don't know what a Zend Optimizer is, but it apparently does not play well with SELinux. I've encountered a blog entry by someone who has tried to do the right thing and keep SELinux enabled, after finding the code for a policy module which makes this stuff work.
I was surprised when I saw the source of the module, which includes:
allow httpd_t self:process execstack;
allow httpd_t self:process execmem;
allow httpd_t self:process execheap;
allow httpd_t usr_t:file execute;
When loaded, this will enable the web server to execute memory on its heap, stack or certain types of executable memory allocated via mmap(2). These are well-known attack vectors and disable some very important memory protection mechanisms. See Ulrich Drepper's SELinux Memory Protection Tests for details.
The file execute permission is also very concerning, as it allows the web server to execute generically labeled user files. Combined with disabled memory protections, and third-party software using unsafe memory execution techniques, I'd recommend being cautious about deploying this solution.
What I would suggest, if you don't understand the security policy, is to run it by your nearest SELinux community. Many mailing lists and IRC channels exist where people will be able to help: see User Resources from the SELinux Project Wiki.
It's important to note that whatever this code is supposed to be doing (apparently, dealing with some form of source code obfuscation), techniques such as making a stack executable are inherently insecure and should never be necessary.
SELinux really is trying to help you here, and free expert advice is merely an email away. At the very least, someone will be able to explain what the risks are, and help you make an informed decision on how to proceed: perhaps it will be better for your particular requirements to allow certain accesses rather than disabling SELinux for the entire system. And if the code is not trying to do something dangerous, an SELinux developer may write a simple module for you to load to work around the issue.
Tags: linux, php, security, selinux, web
I'm sure Zend Optimizer is a JIT compiler. I really wish the default SELinux policy wouldn't break JIT compilation, because JITs tend to be heavily used by managed code like Java/Ruby/Python/etc., and using managed code *greatly* increases security.
Do you really want this happening in the context of a network facing application?
(In any case, see the upcoming typebounds work from KaiGai Kohei which will allow threads to transition a constrained subset of policy, which should help in many of these cases).
Definitely, we should be encouraging managed code - there is far less to worry about because (short of bugs in the JIT) it's impossible to have buffer overflows and the like which account for almost all of the "execute arbitrary code" type of flaw.
It of course doesn't prevent all security issues and SELinux has an important role to play there, but I do think it is rather bad that one security mechanism is breaking another by default.
I'm not sure how a policy *subset* would help, if the JIT compiler thread needs *increased* privileges to get execmem to be able to write code.
Yep, the memory permission issue can't be solved with bounded types, and in fact can't be solved unless the JIT is running in a different process. I wonder what the performance overhead could be reduced to.
|Date:||September 4th, 2008 07:58 pm (UTC)|| |
appears to be a runtime for a PHP encoding tool, Zend Guard
. Given what you've found in terms of that "make it work with SELinux" module, I'd guess that it decodes PHP instructions on the fly and then executes them out of the stack/heap/memory (perhaps some combination of all of them). Presumably such a policy was developed by looking at AVCs and enabling things until it worked, without neessarily understanding what else was permitted by the things enabled.
Unfortunately IME the range of things that various web applications want to do inside the webserver is huge, and most of them have been written without much of an eye on security let alone SELinux in mind. So using SELinux on a non-trivial web application is challenging. As much as allowing executing arbitrary code injected into memory is a bad idea, it's probably still a bit of an improvement over just turning off SELinux for the webserver application completely.