httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <graham.dumple...@gmail.com>
Subject Re: [RFC] A new hook: invoke_handler and web-application security
Date Thu, 09 Apr 2009 06:35:09 GMT
2009/4/9 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> Graham Dumpleton wrote:
>> 2009/4/9 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>>> William A. Rowe, Jr. wrote:
>>>> KaiGai Kohei wrote:
>>>>> However, SElinux does not allow to revert its privilege (security context)
>>>>> unconditionally, even if it is dynamically changed.
>>>>> If we want to revert it, the security policy has to allow B->A in
addition
>>>>> to A->B, but it is generally nonsense.
>>>>> It is also the reason why we need a one-time thread or process to assign
>>>>> individual privileges for each requests.
>>>> Sounds like it's time for you to hack up an alternate, selinux based mpm.
>>> I also think a selinux based (or possible for other secure os) mpm
>>> is a reasonable candidate.
>>>
>>> Due to the above limitation, this mpm need to create a process or
>>> thread for each requests, and not to allow keep-alive mode.
>>>
>>> If the approach can be acceptable, I will switch to develop the new
>>> mpm approach.
>>
>> Which gets back to the old perchild MPM perhaps being in part
>> relevant. The difference is that you need a more dynamic system
>> whereby which specific user process is used might be based on URL or
>> authentication credentials as well as host. Another aspect worth
>> consideration is a means to dynamically create additional processes
>> for new users, rather than everything being static, with an idle
>> timeout mechanism to shutdown user processes which haven't had to
>> handle requests for some amount of time. This approach obviously need
>> not even involve SELinux specifically as separation achieved at
>> process
>> level.
>
> I also think the mpm is not necessary to focus on SELinux.
> If it just create a one-time thread or process for each request,
> an pluggable module can set privileges of the execution context.
> It gives a chance for users to assign SELinux's privileges.
> In addition, someone may choose other operating system.
>
>> FWIW, this dynamic user process creation is something which is being
>> implemented in Apache module I develop. That though is being done at
>> higher level and only applies to the web applications written in the
>> specific scripting language that the module supports, and isn't a
>> generic mechanism applicable to all Apache modules.
>
> Hmm... what I would like to achieve is a bit different.

Although what I am working on is for a specific scripting language,
the concept is just as applicable at the MPM level and so would
achieve what you want if implemented at that level. The existing
perchild MPM already in part illustrates that.

> The reason why I would like to set privilege prior to the invocation
> of contents handler is to apply consistent access controls independent
> from what kind of script languages are used.

I understand that, but you seem to be focused on the idea of using
threads within a process and thus require SELinux security contexts,
with its limitations. If distinct processes are used, and they need
not be created for just a single request but held around while ever
their is activity related to that user, then you do not need SELinux
and so it is portable across more platforms. SELinux security contexts
would only be relevant to a process oriented solution if for some
reason you wanted to set greater constraints than what a user would
normally have imposed on them for a normal process run as that user.

Graham

Mime
View raw message