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/

[ reply ]