At Doug's suggestion I'm moving a brief conversation we've had in private
to this list so others can get involved.
I've been following out the security implications of mod_perl here at
Brown University, and from what I can see, enabling it gives people the
same basic access privileges that ExecCGI does. How does it do this?
Well, for one thing, you can inject arbitrary Perl code at any stage in
the Apache request cycle by using a literal
PerlWhateverHandler 'sub { ... }'
in an htaccess file. You can also specify
PerlWhateverHandler Some::Arbitrary::Path::To::An::Arbitrary::Module.pm
I've been thinking that, since giving users the ability to do these
things is essentially like giving them ExecCGI privileges, that these
things should only be allowed where the ExecCGI option is turned on.
There's also the problem, if a person can ExecCGI, that they can then
use Apache (), and then access all dir_config, notes, and other settings.
At times it may be useful for a systems administrator to create private
dir_config variables that run-of-the-mill CGI scripts simply can't see.
These are two separate issues, of course.
The more pressing one, I think, is the first, namely that we need to
tie the ability to use arbitrary Perl subroutines and arbitrary Perl
modules (i.e., modules in non-system paths) to the ExecCGI option.
I realize that forcing us all to turn ExecCGI on for directories where
we want to use arbitrary Perl subroutines would be a bit of a pain at
this point. So for the current 1.24_0x series I'd suggest adding some
new "paranoid" compile-time option that would deny arbitrary subs and
modules in non-system paths unless ExecCGI is enabled. Another idea
that I haven't really thought through would be to create some new
PerlLiteralSubs On|Off directive that could not be overridden once
turned on.
For the future, though, it might be useful to tie arbitrary subs and
the ability to use Perl modules to ExecCGI. ExecCGI-like privileges
something a sysadmin should always have to decide to do. My sense is
that they should never be turned on implicitly, e.g., by simply adding
and enabling a module.
Does this make sense to anyone else?
--
Richard Goerwitz [EMAIL PROTECTED]
