RE: security suggestion
On Fri, 17 Nov 2000, mgraham wrote: Maybe another approach would be to explicitly list the handlers that are allowed to be used in any given context. Kind of like 'Options', but for perl handlers. Something like 'PerlOptions', perhaps? Location /users PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler" /Location something like that is already implemented in mod_perl-2.0: http://perl.apache.org/~dougm/modperl_2.0.html probably will not happen for 1.xx
Re: security suggestion
In the context of what you are talking about, I think giving ExecCGI permissions should not allow them to change mod_perl handlers or do anything to adjust mod_perl either. ExecCGI is a lot less problematic than exposing access to mod_perl from a shared web server security standpoint especially if CGI's are suexec'ed. So I would advocate an ExecModPerl option or something like that so that user's could not arbitrarily install their own Perl Handlers. At 12:20 PM 11/19/2000 +, Richard Goerwitz wrote: Gunther Birznieks wrote: The CGI scripts on your site would not be passed through Apache::Registry or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense as a motivation to allow mod_perl on a server for content handlers that are tightly defined. But don't allow the users access to anything else in mod_perl. Precisely. I feel as though I've been explaining myself poorly because I've been so widely misunderstood. But what you said above about sums it up. I'm only talking about giving people access to specific mod_perl modules (or to modules in very specific places). I don't want to give people blanket Apache::Registry access as part of that package (except in cases where I specifically say so). At the risk of repeating myself, I'm looking for a way of setting up mod_ perl so that, if I turn off ExecCGI for a given directory (and maybe spe- cify a list of Perl modules or paths), it will mean that, as far as mod_perl is concerned, 1) users can only use specific modules (or modules in specific places) 2) users can't (by implication) use Apache::Registry unless I say so 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv) 4) users can't include any Perl code indirectly or otherwise (e.g., Perl) Re (1) above, I wonder whether it matters if modules I allow load modules that I _don't_ allow. My sense is that as long as I can control the ini- tial loading, I don't care whether the thing that's loaded runs amok. It is my responsibility (if I allow access to a module) to make sure that module will behave itself. Those more versed in security issues will perhaps want to think this through. I've been receiving a steady trickle of off-list mail, by the way, from ISPs and webmasters/sysadmins working in organizations where you just can't allow everyone CGI access (or full mod_perl/Perl access) - but where it would be very useful to allow people selective access to specific Perl modules. They are excited by the thought that they could offer new functionality (and added value) to their services, without necessarily having to trust all their web users (publishers, web developers - whatever) enough to allow them to execute arbitrary Perl code. Those of you who are working on your own, or in small/controlled shops, may not have an intuitive grasp of the circumstances the rest of us work under. But if you think about how things must be for us (some of us w/ hundreds, if not thousands, of web developers), you'll see that we can't monitor every account and audit every change. Universities with lots of student workers/accounts are classic cases. Students are smart and mis- chievous, and they come and go regularly. They make web pages and sys- tems, and they do the same part-time for departments and workgrous with- in the institution. We may want to give them access to a specific Perl module (e.g., some institution-wide authentication system that's imple- mented with a PerlAuthenHandler). But we certainly don't want giving them that sort of access to open up a floodgate by allowing them to exe- cute arbitrary Perl code on the server - unless we say so (e.g., by giv- ing them ExecCGI permission). -- Richard Goerwitz PGP key fingerprint:C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote:
At the risk of repeating myself, I'm looking for a way of setting up mod_
perl so that, if I turn off ExecCGI for a given directory (and maybe spe-
cify a list of Perl modules or paths), it will mean that, as far as mod_perl
is concerned,
1) users can only use specific modules (or modules in specific places)
2) users can't (by implication) use Apache::Registry unless I say so
3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv)
4) users can't include any Perl code indirectly or otherwise (e.g.,
Perl sections, literal 'sub { ... }'s as handlers)
...I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
Some thoughts:
If a user has ExecCGI privileges he or she can commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications of turning it
on (i.e., they'll know that turning it on means the ability to execute code
on the server, using the ID under which Apache runs). And re-using ExecCGI
would relieve us of having to reserve another (mostly redundant) word.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
At 08:42 AM 11/20/00 -0500, Richard L. Goerwitz wrote:
Gunther Birznieks wrote:
At the risk of repeating myself, I'm looking for a way of setting up mod_
perl so that, if I turn off ExecCGI for a given directory (and maybe spe-
cify a list of Perl modules or paths), it will mean that, as far as
mod_perl
is concerned,
1) users can only use specific modules (or modules in specific places)
2) users can't (by implication) use Apache::Registry unless I say so
3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv)
4) users can't include any Perl code indirectly or otherwise (e.g.,
Perl sections, literal 'sub { ... }'s as handlers)
...I would advocate an ExecModPerl option or something like that so that
user's could not arbitrarily install their own Perl Handlers.
Some thoughts:
If a user has ExecCGI privileges he or she can commandeer the most important
part of the request cycle (the response phase), so I'm not sure we get
better
security or control by having a separate ExecModPerl option.
I don't think that this is the case if you configure apache to use suexec
option. With suexec, the CGI script a user invokes cannot even run with
the permissions of the web server, it runs with the permissions of the
individual user. No scripts can trample over each other (other than a
denial of service on CPU and disk) maliciously. But if you open up
mod_perl, then you give the user power over the entire web server including
the prospective capability to hijack another user's URLs.
I do believe there would be ISPs that would enable CGI and special mod_perl
handlers, but not want to enable a user installing their own handlers.
NB: If we re-use ExecCGI for mod_perl, people will feel as though they're
on familiar turf. Sysadmins will understand the implications of turning it
on (i.e., they'll know that turning it on means the ability to execute code
on the server, using the ID under which Apache runs). And re-using ExecCGI
would relieve us of having to reserve another (mostly redundant) word.
I am not sure I agree that ExecCGI gives similar power as mod_perl based on
the argument of suexec behavior.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard L. Goerwitz" [EMAIL PROTECTED] wrote: Gunther Birznieks wrote: ...I would advocate an ExecModPerl option or something like that so that user's could not arbitrarily install their own Perl Handlers. If a user has ExecCGI privileges he or she can commandeer the most important part of the request cycle (the response phase), so I'm not sure we get better security or control by having a separate ExecModPerl option. NB: If we re-use ExecCGI for mod_perl, people will feel as though they're on familiar turf. Sysadmins will understand the implications of turning it on (i.e., they'll know that turning it on means the ability to execute code on the server, using the ID under which Apache runs). And re-using ExecCGI would relieve us of having to reserve another (mostly redundant) word. I don't think it's redundant at all. In fact it is already possible to configure a Location or VirtualHost section within a mod_perl server in which mod_perl functionality is disabled (or overridden) with an old-style ExecCGI directive (scripts fork into separate SUID user-owned processes). In that scenario, which is not as unlikely as it might at first seem, for an ISP, the directive ExecCGI already has meaning, and "reusing it" would cause some bad ambiguouity. -dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Gunther Birznieks" [EMAIL PROTECTED] wrote: In the context of what you are talking about, I think giving ExecCGI permissions should not allow them to change mod_perl handlers or do anything to adjust mod_perl either. ExecCGI is a lot less problematic than exposing access to mod_perl from a shared web server security standpoint especially if CGI's are suexec'ed. So I would advocate an ExecModPerl option or something like that so that user's could not arbitrarily install their own Perl Handlers. [snip] 1) users can only use specific modules (or modules in specific places) 2) users can't (by implication) use Apache::Registry unless I say so 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv) 4) users can't include any Perl code indirectly or otherwise (e.g., Perl) It seems like what you're really asking for is some sort of "LessModPerl" directive that disallows raw perl (perl sections, PerlModule and PerlRequire directives, others?) in .htaccess and limits @INC within .htaccess to a certain path, but allow users to add PerlSetVar youconfigvalue PerlHandlder YourPredefined::handlers to their .htaccess sections I agree - this has very useful applications in shared hosting. Having developed on large shared-server ISPs that successfully manage multiple developers, I've always thought it was going to be problematic for ISP's to deploy it because all of mod_perls power is just as easily invoked from .htaccess as it is from conf files (where the shared users are forbidden to go). that's where to enforce the security. administrators need to be able to set up the server conf files such that users can use .htaccess to configure what mod_perl handlers they want to use, but they can't specify handlers outside of a read-only (to them) "handlerlib" area and so cannot write their own handlers, "PerlRequire" scripts, or "PerlModule" modules. -dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote: The CGI scripts on your site would not be passed through Apache::Registry or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense as a motivation to allow mod_perl on a server for content handlers that are tightly defined. But don't allow the users access to anything else in mod_perl. Precisely. I feel as though I've been explaining myself poorly because I've been so widely misunderstood. But what you said above about sums it up. I'm only talking about giving people access to specific mod_perl modules (or to modules in very specific places). I don't want to give people blanket Apache::Registry access as part of that package (except in cases where I specifically say so). At the risk of repeating myself, I'm looking for a way of setting up mod_ perl so that, if I turn off ExecCGI for a given directory (and maybe spe- cify a list of Perl modules or paths), it will mean that, as far as mod_perl is concerned, 1) users can only use specific modules (or modules in specific places) 2) users can't (by implication) use Apache::Registry unless I say so 3) users can't change PERL5LIB or use PerlSetEnv (or PerlPassEnv) 4) users can't include any Perl code indirectly or otherwise (e.g., Perl) Re (1) above, I wonder whether it matters if modules I allow load modules that I _don't_ allow. My sense is that as long as I can control the ini- tial loading, I don't care whether the thing that's loaded runs amok. It is my responsibility (if I allow access to a module) to make sure that module will behave itself. Those more versed in security issues will perhaps want to think this through. I've been receiving a steady trickle of off-list mail, by the way, from ISPs and webmasters/sysadmins working in organizations where you just can't allow everyone CGI access (or full mod_perl/Perl access) - but where it would be very useful to allow people selective access to specific Perl modules. They are excited by the thought that they could offer new functionality (and added value) to their services, without necessarily having to trust all their web users (publishers, web developers - whatever) enough to allow them to execute arbitrary Perl code. Those of you who are working on your own, or in small/controlled shops, may not have an intuitive grasp of the circumstances the rest of us work under. But if you think about how things must be for us (some of us w/ hundreds, if not thousands, of web developers), you'll see that we can't monitor every account and audit every change. Universities with lots of student workers/accounts are classic cases. Students are smart and mis- chievous, and they come and go regularly. They make web pages and sys- tems, and they do the same part-time for departments and workgrous with- in the institution. We may want to give them access to a specific Perl module (e.g., some institution-wide authentication system that's imple- mented with a PerlAuthenHandler). But we certainly don't want giving them that sort of access to open up a floodgate by allowing them to exe- cute arbitrary Perl code on the server - unless we say so (e.g., by giv- ing them ExecCGI permission). -- Richard Goerwitz PGP key fingerprint:C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
I think Randal was making a similar point I was making last night (SG time). That as long as you execute Perl code, you can manipualte the memory space of Perl (and hance change the behavior of Apache::Registry). But you explained it in your reply to me. Basically you want explicit handlers that are tightly defined to run but you aren't talking about allowing users to run Apache::Registry scripts arbitrarily. Just explicitly defined pieces of code like a handler for counter() logic. The CGI scripts on your site would not be passed through Apache::Registry or Apache::PerlRun, they would run as normal CGIs. No? So that makes sense as a motivation to allow mod_perl on a server for content handlers that are tightly defined. But don't allow the users access to anything else in mod_perl. At 04:36 PM 11/17/00 -0500, Richard L. Goerwitz wrote: "Randal L. Schwartz" wrote: I think y'all are missing it. As soon as I have any Perl code access via Apache::Registry or anything like that, I can do this: *Apache::Registry::handler = \my_trojan_horse; Can you explain in what server-configuration context the above directive would be executed? (I'm not disputing anything you say; just trying to follow.) -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
I think these are good points. However, to some degree, if this is an attempt to allow an ISP protection, it's not because most ISPs offer CGI access to their customers. In addition, the moment you give mod_perl access to a developer they have the rights to do a LOT of stuff that goes beyond putting PerlHandlers in an htaccess file. It's possible to go through the Apache::Registry package and walk the subroutine tree of precompiled scripts and conceivably figure out stuff about other people's scripts. Actually probably easier to just figure out what packages exist in memory and walk the memory and variables directly. If some of those variables are config vars, then oh well. In fact, I should think it is conceivable that one mod_perl script could theoretically replace another mod_perl script within the Apache::Registry by manipulating the global variables within Apache::Registry. So in other words, if you can't have a semblance of trust your developers against each other, then mod_perl simply cannot be configured in a way that developers can truely share the same web server. However, I don't think many people advocate sharing mod_perl web servers in teh real world with apache 1.3. When Apache and mod_perl 2.0 come out, I suspect the new architecture will allow very cool things like Perl Interpreter segmentation among virtual hosts. But until that happens, there's really not much you can do. It seems to me that mod_perl wasn't really designed for safety against your own developers doing something malicious. And most if not all people pretty much run their servers that way. Most people who run mod_perl run it as their own dedicated server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Gunther Birznieks wrote:
It seems to me that mod_perl wasn't really designed for safety against your
own developers
I accept this point. But it's really beside _my_ point, which was that
mod_perl modules can offer critical added functionality to run-of-the-mill
web publishers (whether it be a counter, a new authentication method, a
special content handler, or just some thingie I wrote for them). I think
it would be great to be able to offer web publishers the ability to _use_
those modules without giving them direct access to Perl.
Not all shops consist of a small group of twenty-something developers who
all eat pizza and beer together on Fridays. Many of us operate in hetero-
geneous environments with hundreds, if not thousands, of web "developers"
who are part of our community, and who may really need some custom modules
written for them, but who I can't be bothered monitoring on a day-to-day
basis - and who I don't want to grant blanket access to my server inter-
nals to.
Let me return to my C module analogy. When I compile in mod_auth_dbi, I
am giving users added functionality. But I'm not giving them the ability
to execute arbitrary C code. I think everyone would agree that this is a
useful (no, critical) feature of Apache.
I simply want to be able to do the same thing in Perl with mod_perl. I
want to be able to give developers ("users" - whatever you want to call
them) added functionality, without giving them the ability to execute
arbitrary Perl code.
I'd have no problem if mod_perl was set up to turn off PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of Perl modules
in non-system paths (except where ExecCGI is turned on). I don't know
what else would need to be done, but it all strikes me as critical to
the use of mod_perl in shops that don't fit the "pizza and beer" model
that something along these lines be done.
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard I simply want to be able to do the same thing in Perl with mod_perl. I
Richard want to be able to give developers ("users" - whatever you want to call
Richard them) added functionality, without giving them the ability to execute
Richard arbitrary Perl code.
Use Template Toolkit, and disable the "EVAL_PERL" option for their space.
Set up Plugins and Filters that call your Cool Perl Code.
Then they write arbitary text files to be delivered, but when they
want your added functionality, all they can do is call your interfaces
using the mini-Toolkit language embedded in their files.
And they get a slick templating system for free!
Best of both worlds.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Randal L. Schwartz" wrote: Use Template Toolkit, and disable the "EVAL_PERL" option for their space. Set up Plugins and Filters that call your Cool Perl Code. Then they write arbitary text files to be delivered... Suppose it were possible to set Perl-based modules to work the same way C modules currently do (in the sense that they let you offer developers, users, etc. access to the module without letting them execute arbitrary code on the server). Would you agree that this would be a good thing? Your solution above is great. But it's another one of those "I have a workaround" suggestions. I wonder if there is a way to skip the workarounds. If there is, would you agree that it would be a good (no, wonderful) thing? And would you agree that, if it's possible to do it, mod_perl would be more useful if it were set up in such a way that merely enabling it didn't essentially give everyone with access to the webserver's docroot the ability to execute arbitrary Perl? I'm interested in knowing what's possible here. My knowledge of mod_ perl right now is pretty good, from a module developer's standpoint. I'm just not familiar enough (yet) with its internals to be able to think and speak creatively about the security possibilities. -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security suggestion
I'd have no problem if mod_perl was set up to turn off
PerlSetEnv, lit-
eral 'sub { ... }' handlers, Perl sections, and the use of
Perl modules
in non-system paths (except where ExecCGI is turned on).
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
/Location
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
mgraham wrote:
Maybe another approach would be to explicitly list the handlers that
are allowed to be used in any given context. Kind of
like 'Options', but for perl handlers. Something like 'PerlOptions',
perhaps?
Location /users
PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
/Location
That's a neat idea.
The only quibble I can think of is that this doesn't go far enough.
This lower level of privilege we're talking about is one in which -
1) Only specific Perl modules are available (or ones in specific
paths; no literal 'sub { ... }' handlers)
2) PerlSetEnv (and PerlPassEnv?) aren't usable
3) PERL5LIB isn't changeable
4) Perl sections are unavailable
--
Richard Goerwitz[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Richard" == Richard L Goerwitz [EMAIL PROTECTED] writes:
Richard That's a neat idea.
Richard The only quibble I can think of is that this doesn't go far enough.
Richard This lower level of privilege we're talking about is one in which -
Richard 1) Only specific Perl modules are available (or ones in specific
Richard paths; no literal 'sub { ... }' handlers)
Richard 2) PerlSetEnv (and PerlPassEnv?) aren't usable
Richard 3) PERL5LIB isn't changeable
Richard 4) Perl sections are unavailable
I think y'all are missing it. As soon as I have any Perl code access
via Apache::Registry or anything like that, I can do this:
*Apache::Registry::handler = \my_trojan_horse;
Unless you use "Safe", any access to any Perl invocation means you are
insecure.
So mod_perl is inherently unsafe. Either you have access to Perl, or
you don't. And when you don't, you might as well invent a meta-API,
like the one I suggested with Template Toolkit. You can't use the
generic tools... they're too powerful.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
"Randal L. Schwartz" wrote: I think y'all are missing it. As soon as I have any Perl code access via Apache::Registry or anything like that, I can do this: *Apache::Registry::handler = \my_trojan_horse; Can you explain in what server-configuration context the above directive would be executed? (I'm not disputing anything you say; just trying to follow.) -- Richard Goerwitz[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security suggestion
Following up on the security suggestion (I'm actually responding to private mail, so I'll just quote the person who wrote to me without giving a name) - Of course you can do this in an .htaccess file, too: Perl arbitrary perl code... /Perl I'd argue that people shouldn't be able to do that - unless, of course, they can ExecCGI. The general idea is this: Regular users without ExecCGI may have good reason to say things like, PerlAuthenHandler Apache::SomeNewAuthModule E.g., suppose you want them to be able to use some local secure cookie- based auth handler. Or they may want to use a locally written response handler that converts HTML to XHTML on the fly - or innumerable other modules. Although we want those users to have access to these modules (and to the added functionality they bring), we may not want them to be able to execute arbitrary Perl code. And if we DO want them to execute arbitrary Perl code, we should have to explicitly grant them permission to do it. Permission shouldn't be granted implicitly by doing something else (e.g., by enabling another module like mod_perl). My sense is that the existing ExecCGI mechanism is a perfectly reasonable way of handling the permissions here, since being able to execute arbi- trary Perl code is basically the same as ExecCGI privileges (it's a bit more powerful, but why introduce more options if we don't really need to?). -- Richard Goerwitz[EMAIL PROTECTED]
RE: security suggestion
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 10:11 AM
To: [EMAIL PROTECTED]
Cc: Geoffrey Young
Subject: Re: security suggestion
Following up on the security suggestion (I'm actually responding to
private mail, so I'll just quote the person who wrote to me without
giving a name) -
Of course you can do this in an .htaccess file, too:
Perl
arbitrary perl code...
/Perl
I'd argue that people shouldn't be able to do that - unless,
of course,
they can ExecCGI.
The general idea is this: Regular users without ExecCGI may have good
reason to say things like,
PerlAuthenHandler Apache::SomeNewAuthModule
but what about
PerlSetEnv PERL5LIB '/my/lib/'
PerlAuthenHandler My::Handler
there's nothing that says an AuthenHandler has to authenticate :)
maybe it would be possible to limit
PerlAuthenHandler 'sub {do something desctructive};'
via a directive, but this is mod_perl - I can't see how you would be able to
allow good activity without there being some way around it for destructive
types...
at least not in a generic sense - you could write an Init handler that
pushes Your::Validator to the front of each phase which runs all configured
handlers through various checks (of course one that seemed valid could push
another bad handler to the stack on the fly)
see what I mean - protection is not guaranteed...
Although we want those users to have access to these modules
(and to the
added functionality they bring), we may not want them to be able to
execute arbitrary Perl code.
PERL_SECTIONS=0 at build time can deactivate this across the board
--Geoff
RE: security suggestion
Perhaps you ought to gfind a way to use Safe; then?
-Original Message-
From: Richard L. Goerwitz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 9:09 AM
To: mod_perl list
Subject: security suggestion
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]
RE: security suggestion
Maybe it's just me, but it seems that the responses richard has gotten haven't really touched on the core of the problem. That mod_perl isn't exactly friendly to sysadmin's who want to run apache on a (i'm guessing), student accessed server, with user dir's and all that other stuff. I'm pretty sure (for no particular reason), that there aren't many people on this list that are doing that. If you have .htaccess stuff turned on right now, you can do all sorts of great things through apache that you wouldn't want untrusted accounts on the box being able to do. The servers that had apache on them for users when i was at school didn't even allow normal cgi, so i have no idea how one would approach doing something like this with mod_perl. If, on the other hand, i'm misinterpreting richards problems, feel free to ignore me. Adam
RE: security suggestion
The thing is, though, that as a web administrator I don't want those same developers (or at least all of them) to be able to create and in- stall _arbitrary_ handlers or arbitrary perl code. Sometimes the de- velopers just don't know enough. And sometimes I just don't trust them enough to allow it. And just putting your configuration for their portion of the site into the main configuration files would be insufficient? Christian
Re: security suggestion
"Adam Prime" [EMAIL PROTECTED] wrote:
Maybe it's just me, but it seems that the responses richard has gotten
haven't really touched on the core of the problem. That mod_perl isn't
exactly friendly to sysadmin's who want to run apache on a (i'm guessing),
student accessed server, with user dir's and all that other stuff. I'm
pretty sure (for no particular reason), that there aren't many people on
this list that are doing that.
I assumed the question was related to the situation of an ISP (or more specifically
web hosting provider) who wants to offer some mod_perl functionality to users on a
shared server. the environment may be similar to the educational scenario, but the
difference is that a web presence provider that is "first" to offer mod_perl (at
prices competitive with oher shared hosting services) stands to differentiate itself
ffrom it's competition and see a signficant revenue reward for it's efforts, either
from being able to charge extra for the mod_perl add-on service, or simply as a swell
of users flock to signup for new service there.
It's an interesting problem in that context. offering mod_perl in such an environment
"safely" would be a big advantage to my hosting provider for instance (pair.com) who
*does* offer custom CGI, is extremely developer-friendly (supports perl, C, php and
python CGI) but has so many users sharing the same httpd that the mod_perl problems
are many and varied. we can't access .conf files or restart apache so we're limited
to .htaccess configuration.
There are so many active developers already that they run "reaper" processes on each
server to kill runaway scripts, and enforce resource limits on user processes.
If they could enforce these rlimits and automatically kill runaway code in users'
mod_perl processes, and *if* those user scripts could be isolated such that they can't
bring down the parent httpd process, mod_perl would be an awesome feature of the
service!
...If you have .htaccess stuff turned on right
now, you can do all sorts of great things through apache that you wouldn't
want untrusted accounts on the box being able to do.
right. it seems like raw perl in .htaccess files would almost *have* to be disabled.
or would it? bad/uncompilable code in .htaccess would just affect the requests that
invoked it, not the parent process...
as long as the server is running as an unpriveledged nobody-user or SetUID as the
~/user who is owns it, the security concerns should be minimal. if a mod_perl process
can attain root priveledges that would, uh, be a bad thing :-)
Of course, in such a restricted environment, many of mod_perl's advantages would be
nullified; scripts would not stay compiled in memory, and modules would be reloaded
on every request (since editing conf files or startup.pl or restarting apache isn't
possible). But hooking into the auth process alone would add a LOT of flexibility to
the many sites hosted on shared servers there.
plus there are endless support requests on "how to do this or that with mod_rewite
regexps"... (i agree with Randal here... how did that ever catch on? heheh).
rewriting and redirecting with mod_perl is *so* much simpler and more flexible.
The servers that had apache on them for users when i was at school didn't
even allow normal cgi, so i have no idea how one would approach doing
something like this with mod_perl.
right. many (lazy) commercial web hosting providers don't even (to this day) offer
perl CGI either. But most decent ones have realized that even the unwashed masses
need perl scripts to run, and have already successfully addressed ExecCGI security
issues in order to remain competitive.
pair has even recently begun to equip servers with mod_php... but i think mod_perl has
been deemed too powerful for use on shared servers, for now... {sigh}
-dave (secretly hoping that the mod_php scripters here crash the servers with endless
loops and stuff)
