Joe Orton wrote: > On Wed, Apr 08, 2009 at 10:38:52AM +0900, KaiGai Kohei wrote: >> 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 traditional threat model people try to address here is of e.g. > trying to run untrusted PHP code using the in-process interpreter. > Because PHP lacks any kind of sandboxing this is equivalent to running > arbitrary code in an Apache child, so it's not really safe to run > untrusted PHP code in this way. > > Your approach here is to spawn a thread and ensure that thread runs in a > lower-privileged SELinux domain. So the admin can then restrict the > ability of the handler to manipulate the filesystem and interact with > the OS, which seems somewhat useful. > > But it's a half-way house between no security and the security which can > achieved using a process separation model like e.g. FastCGI. Many of > the problems of using in-process PHP code are not addressed - e.g. of > access to any SSL private keys in the memory space.
Correct. As I noted, SELinux does not prevent accesses information which is already loaded into process local memory. > So I'm not sure that it's worthwhile. Having said that, it seems a lot > more worthwhile than the mod_privileges approach in the trunk, which > seems to claim it is secure so long as you don't execute untrusted code, > so I'm not sure what threat model that addresses at all. We can consider the model using an analogy. When we access a file, we need to login the system and give a few operations to shell process as an agent of us. In this case, we have to be identificated and authorized prior to any operations on the system. In addition, the system assigns appropriate privileges on the agent (shell process) based on the result of authentication. It restricts all the operations on the system. In web system, web-application can perform as an agent of us. When we give operations as a request, web server often requires us to be authenticated, and it invokes web-application instance, but it does not assign individual privileges. Thus, we need to trust web application performs correctly and its access controls are comprehensive. We consider web-application instance as an agent of users, so an appropriate privileges should be assigned on them, based on the result of identification and authentication. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com>
