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. 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. Regards, Joe
