Re: [RFC] A new hook: invoke_handler and web-application security
2009/4/9 KaiGai Kohei kai...@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. 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. Graham
Re: [RFC] A new hook: invoke_handler and web-application security
2009/4/9 KaiGai Kohei kai...@ak.jp.nec.com: Graham Dumpleton wrote: 2009/4/9 KaiGai Kohei kai...@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
Re: [RFC] A new hook: invoke_handler and web-application security
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. Yes, the thread level privilege is a characteristic in SELinux, thus it may prevent to port the feture to other platforms. At least, I don't have any preference between them to implement the security focused mpm. I can agree the mpm should create a process rather than a thread. However, I don't think it is reasonably possible a process to handle multiple requests, because authentication header is come for each times, so we cannot assume the second request should be handled with same privilege of the first one. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
Re: [RFC] A new hook: invoke_handler and web-application security
Graham Dumpleton wrote: 2009/4/9 KaiGai Kohei kai...@ak.jp.nec.com: 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. Yes, the thread level privilege is a characteristic in SELinux, thus it may prevent to port the feture to other platforms. At least, I don't have any preference between them to implement the security focused mpm. I can agree the mpm should create a process rather than a thread. However, I don't think it is reasonably possible a process to handle multiple requests, because authentication header is come for each times, so we cannot assume the second request should be handled with same privilege of the first one. I am not talking about successive requests over a keepalive socket, but totally distinct requests, where distinct decision is made as whether those requests should be passed through to the appropriate user process. You really need to look at how perchild is implemented. Now I'm looking at the perchild implementation... Since I could not find it at the 2.2.x tree, I refer the 2.0.x tree. Is it correct for what you intend? From the quick overview, if I can understand correctly, it seems to me the perchild uses longjmp() to rewind the steps when an unexpected process receives a request for other virtual host. It makes decision at the post_read_request hook after the ap_update_vhost_from_headers(), but we need to do same thing at more deep stage (fixups?). It is unclear for me whether it really has an advantage rather than per-request creation design. Please tell me, if I'm looking at something pointless. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
Re: [RFC] A new hook: invoke_handler and web-application security
2009/4/9 KaiGai Kohei kai...@ak.jp.nec.com: Graham Dumpleton wrote: 2009/4/9 KaiGai Kohei kai...@ak.jp.nec.com: 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. Yes, the thread level privilege is a characteristic in SELinux, thus it may prevent to port the feture to other platforms. At least, I don't have any preference between them to implement the security focused mpm. I can agree the mpm should create a process rather than a thread. However, I don't think it is reasonably possible a process to handle multiple requests, because authentication header is come for each times, so we cannot assume the second request should be handled with same privilege of the first one. I am not talking about successive requests over a keepalive socket, but totally distinct requests, where distinct decision is made as whether those requests should be passed through to the appropriate user process. You really need to look at how perchild is implemented. Now I'm looking at the perchild implementation... Since I could not find it at the 2.2.x tree, I refer the 2.0.x tree. Is it correct for what you intend? From the quick overview, if I can understand correctly, it seems to me the perchild uses longjmp() to rewind the steps when an unexpected process receives a request for other virtual host. It makes decision at the post_read_request hook after the ap_update_vhost_from_headers(), but we need to do same thing at more deep stage (fixups?). It has been a very long time since I looked at the code that implements it. Either way, the intent in pointing it out was more the architecture it uses rather than exactly how it is implemented. It is unclear for me whether it really has an advantage rather than per-request creation design. For per request you mean a new process, then it should as far as performance is concerned as the cost of a CGI like model of a new process per request is significantly higher than using a persistent process. This is one of the reasons FASTCGI came about in the first place. Please tell me, if I'm looking at something pointless. Only you would know that. But then, I could be pointing you at the wrong MPM. There is from memory another by another name developed outside of ASF which intends to do the same think. The way it is implemented is probably going to be different and may be the one I am actually thinking of. I can't remember the name of it right now. Graham
Re: [RFC] A new hook: invoke_handler and web-application security
On Thursday 09 April 2009, Graham Dumpleton wrote: Only you would know that. But then, I could be pointing you at the wrong MPM. There is from memory another by another name developed outside of ASF which intends to do the same think. The way it is implemented is probably going to be different and may be the one I am actually thinking of. I can't remember the name of it right now. Maybe you mean MPM itk, which can change to different users for different vhosts? http://mpm-itk.sesse.net/
load balancing with Apache for Tomcat workers
Hi All, I want to configure mod_proxy_balancer to distribute load among two back end Tomcat workers. How can I find more information relevant to this. Best Regards, Iroshan
Re: [RFC] A new hook: invoke_handler and web-application security
Stefan Fritsch wrote: On Thursday 09 April 2009, Graham Dumpleton wrote: Only you would know that. But then, I could be pointing you at the wrong MPM. There is from memory another by another name developed outside of ASF which intends to do the same think. The way it is implemented is probably going to be different and may be the one I am actually thinking of. I can't remember the name of it right now. Maybe you mean MPM itk, which can change to different users for different vhosts? http://mpm-itk.sesse.net/ Thanks for your information. It is designed on the prefork. It makes a child process for each connection to call ap_process_connection() in separated context, and the parent waits for the completion of this. In addition, it assigns configured uid/gid on the header_parser hook, then contents handlers are invoked. It seems to me that we can share its basic idea and design. The mpm-itk also has separatable two functionalities: 1. it makes a process for each connection. 2. it assigns privileges on a process. I believe we are now on the right direction. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com
