RE: security suggestion

[Doug MacEachern]

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?
> 
> 
> PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
> 

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

[Dave Kaufman]

"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., )

It seems like what you're really asking for is some sort of "LessModPerl" directive 
that disallows raw 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

[Dave Kaufman]

"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]

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.,
> > >   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]

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

[Gunther Birznieks]

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., )
>
>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

[Richard Goerwitz]

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., )

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

[Gunther Birznieks]

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

[Richard L. Goerwitz]

"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

[Randal L. Schwartz]

> "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)  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]> 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

[Richard L. Goerwitz]

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?
> 
> 
> PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"
> 

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)  sections are unavailable

-- 
Richard Goerwitz[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: security suggestion

[mgraham]

> 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?


PerlOptions "My::AuthHandler My::ContentHandler My::TransHandler"


Michael





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: security suggestion

[Richard L. Goerwitz]

"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

[Randal L. Schwartz]

> "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]> 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

[Richard L. Goerwitz]

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

[Gunther Birznieks]

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

[Dave Kaufman]

"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  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)

Re: security suggestion

[Dave Kaufman]

"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  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)

Re: security suggestion

[James G Smith]

Adam Prime <[EMAIL PROTECTED]> wrote:
>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.

Even more convoluted is when a user can ExecCGI, but only via suexec.  
mod_perl would get around the suexec protections.  Especially on student web 
servers where there are (potentially) 60,000 people wanting to put up web 
pages with CGI.  Thankfully, not all the users want to do this.  But the issue 
is still there.  If someone has mod_perl access, they have access to 
everything the server can access.
-- 
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Texas A&M CIS Operating Systems Group, Unix

RE: security suggestion

[Geoffrey Young]

> -Original Message-
> From: Adam Prime [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 16, 2000 11:46 AM
> To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
> Cc: Geoffrey Young
> Subject: RE: security suggestion
> 
> 
> 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.

I think that's the issue...

I think my last message was misinterpreted.

I do understand why you would _want_ to have the ability to restrict things
the way richard suggests, I just don't think it is possible - there would be
far too many variables to control (PerlSetEnv, Perl*Handler 'sub {}',
, push_handler(), checking PERL5LIB, etc...)

but hey, that's just me.  if someone is brilliant enough to figure it all
out, kudos...

I think I'm done with this one...

--Geoff

RE: security suggestion

[Christian Gilmore]

> 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]

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

[Richard L. Goerwitz]

Geoffrey Young wrote:

> 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...

That's where I disagree.  Perl modules often offer extremely useful
functionality.  They often do things that even ordinary web developers
might want to do.  So I think it's imperative that ordinary web devel-
opers be able to install canned mod_perl handlers that I've written
for them (or installed for them).

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.

But that doesn't mean I want to cut them off from modules I've made
available myself.

Think of it as being like C modules.  Say I want to give them access
to a built-in counter module.  I compile the C module and either load
it dynamically, or build it statically into Apache and enable it.
Either way, they get access to the counter module's functionality.
But the don't, as a side-effect, get to execute arbitrary C code.

Perl modules should work the same way.  I should be able to give them
access to existing modules without giving them access to Perl.  If I
want to give them access to Perl, I should have to do it explicitly.

I've advocated co-opting ExecCGI for this purpose.

We could go the mod_include route, of course, where you get #exec
by default, and only lose #exec via IncludesNoExec.

That could work, too.

> PERL_SECTIONS=0 at build time can deactivate this across the board

IMHO it shouldn't be an all-or-nothing thing.

-- 
Richard Goerwitz[EMAIL PROTECTED]

RE: security suggestion

[Jerrad Pierce]

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

[Geoffrey Young]

> -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:
> >
> > 
> >   arbitrary perl code...
> > 
> 
> 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

[Richard L. Goerwitz]

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:
>
> 
>   arbitrary perl code...
> 

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

[Richard L. Goerwitz]

Would it make sense to allow anonymous subroutines as handlers only if
ExecCGI is turned on for a given directory?  (Likewise, allow handlers
only in modules residing in system directories unless ExecCGI is turned
on?)

-- 
Richard Goerwitz[EMAIL PROTECTED]