Log in

No account? Create an account
SELinux memory protections are your friend - James Morris
September 5th, 2008
12:26 am


Previous Entry Share Next Entry
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: , , , ,

(6 comments | Leave a comment)

Date:September 4th, 2008 05:36 pm (UTC)
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.
Date:September 4th, 2008 10:42 pm (UTC)
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).
Date:September 4th, 2008 11:30 pm (UTC)
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.
Date:September 5th, 2008 12:58 am (UTC)
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.
[User Picture]
Date:September 4th, 2008 07:58 pm (UTC)

Zend Optimizer

Zend Optimizer 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.

Date:September 4th, 2008 10:39 pm (UTC)

Re: Zend Optimizer

There's some upcoming work which will allow confinement of applications within the web server, which should be useful for many cases:

James Morris Powered by LiveJournal.com