On Thu, Feb 05, 2004 at 02:55:41AM +0300, Dan Yefimov wrote: > This means mod_perl must somehow hide all those file handles from the > script being executed. If mod_perl doesn't do that, it's not simply a > design flaw, but it's also a serious security flaw. Dan, do you have any suggestions how portions of a process should 'hide' file handles from other portions of its own address space? [1] Please remember that mod_perl, mod_python, mod_php, etc., were all written to run scripts inside the address space of apache to help speed execution, by removing the fork()/exec() slowdown required to provide a standard privilege barrier. This speed comes at a cost that is acceptable for some users and is unacceptable for other users. Consider, without loss of generality, a server being used to host amazon.com. Amazon could run their perl scripts in mod_perl; as the only user of the system (and presumably they have internal controls to ensure malicious code does not run on their webservers) this is an appropriate choice. Consider a website hosting provider, such as your favourite commercial ISP. They can NOT trust their mutually distrusting users to run code in their webserver's address space -- so, they cannot run mod_perl, mod_python, mod_php, etc. Presumably, the hosting providers can simply buy twice as many machines and slightly raise their prices to their customers. Whether to use mod_perl, mod_python, mod_php, etc., is strictly a per-site decision that every administrator has to make for him or herself, based on that site's security policy. Thanks [1] I'll note that Immunix's Secured Linux Distribution provides exactly such a mechanism, in the form of "change_hat Apache", a patch to our Apache package that makes a system call specific to Immunix's SubDomain mandatory access control mechanism. While this is great for us, it certainly isn't portable to all the platforms that Apache may run on. -- Immunix Secured Linux Distribution: http://immunix.org/
Attachment:
pgppYltLZ3OCr.pgp
Description: PGP signature