httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KaiGai Kohei <>
Subject Re: [RFC] A new hook: invoke_handler and web-application security
Date Wed, 08 Apr 2009 02:19:54 GMT
Graham Dumpleton wrote:
> Explain first why using FASTCGI and suexec wouldn't be a better option?

Thease are limited to cgi applications, so we cannot apply such kind
of restriction on the built-in script languages and references on
static documents (like *.html).

# For example, when we want to assign "webapp_unpriv_t" for anonymous
# users, they should not refer classified files, even if its access
# does not go through either of web applications or httpd.

> It concerns me that in your plans, even though you are changing the
> security context of a single thread within an existing process, that
> that thread may still has access to all the process memory and so
> could read or modify memory in use by threads running in a different
> security context. I am assuming here that SELinux cannot prevent that
> happening.

Yes, but it is fundamentally not different from process separation as
far as it does not change its security context on execve(2).
SELinux makes all the decision when the required actions are happen,
and any information already loaded into process local memory is not
a target of its access controls.
When we change the security context of a process from higher privilege
to lower one dynamically, it has a possibility to contain higher classified
information within its process local memory. It is a restriction of
dynamic context changes.

However, I can agree it can access information which is loaded by another
thread after its security context changed, so its strength is a bit
worth than process level dynamic transtion.


> Graham
> 2009/4/8 KaiGai Kohei <>:
>> Hello,
>> I've posted my idea to improve web-application security a few times
>> however, it could not interest folks unfortunatelly. :(
>> So, I would like to offer another approach for the purpose.
>> The attached patch is a proof of the concept of newer idea.
>> Any comments are welcome, and please feel free.
>> The attached patch adds the following hook:
>>  AP_DECLARE_HOOK(int,invoke_handler,(request_rec *r))
>> The server/core.c registers the ap_invoke_handler() as a default
>> fallback, and all the ap_invoke_handler() invocations are replaced
>> by ap_run_invoke_handler(), so we don't have any compatibility
>> issue as far as no modules uses the new hooks.
>> The purpose of this new hooks is to give modules a chance to assign
>> an appropriate privilege set before contents handler launched.
>> The mod_selinux.c is a typical example.
>> It acquires a control via the invoke_handler hook whenever someone
>> tries to invoke contents handler, then it compute what privilege
>> (called as security context) should be assigned during the contents
>> handler execution. If the computed privilege is same as the current
>> one, it just returns DECLINES. But, if the computed one is different
>> from the current, it creates a one-time worker thread and wait for
>> its completion. The worker thread set a new privilege on itself and
>> invokes ap_invoke_handler() with restricted privilege.
>> In the previous design proposal, I added hooks just before
>> ap_process_(async_)request(), but I noticed it cannot handle a case
>> of internal redirection.
>> BTW, Please note that the purpose of our efforts is to launch web
>> applications with individual privilege set, not to add new hooks.
>> Now I think the idea is the shortest distance to the goal, but
>> is there any other ideas? If you have anything, I would like to
>> see it.
>> Thanks,
>> --
>> OSS Platform Development Division, NEC
>> KaiGai Kohei <>

OSS Platform Development Division, NEC
KaiGai Kohei <>

View raw message