This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Gustavo Vieira Goncalves Coelho Rios
<gustavo@ifour.com.br>
From: Stas Bekman <stas@stason.org>
Subject: Re: security
Date: Thu, 1 Mar 2001 09:44:47 +0800 (SGT)
On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho Rios wrote:
> Hi folks!
>
> I have a FreeBSD server configured as a http server, running apache.
> This installation includes mod_perl+EmbPerl, mod_php4 mod_cgi and
> mod_fastcgi. Some of my users will be using mysql for database. The
> problem is that this scenario requires sensitive information inside
> file. This means no problem when these users write their dymanic pages
> inside a compiled program. I can chmod a-rw and nobody will be able to
> take away user/password from a compiled program. The problem happens
> when write their php or embperl pages!
>
> the key user\password are kept inside this file, so anyone can uses an
> editor to retrieve the user mysql account. I resolve this problem
> running php on secure mode and chgrping the php file the same user as
> the http process and removing other flags file access (g-rwx). So nobody
> besides the owner of the file (or the http process) will be able to read
> it.
>
> since php have some security facilities, like: if the file owner id !=
> the file the script is trying to open => fails.
> My problem is with perl: how to solve such a problem in a perl
> environment?
> Does mod perl allows any kind of security, to prevent ones writing
> script to read others files?
>
>
> PS: All cgi runs through suexec, so even cgi are not able to run the
> script, ok?
At this moment anybody who has an access to mod_perl server can read any
data which is accessible by the same server. suexec is not an option
because of process persistance.
I understand that you want to store the SQL engine authentication info,
and users not to know each other's access credentials. The only solution
at this point is to either trust your users not to abuse each other, or
run a separate server for each one :(
===
To: Stas Bekman <stas@stason.org>
From: Kee Hinckley <nazgul@somewhere.com>
Subject: Re: security
Date: Wed, 28 Feb 2001 22:33:26 -1000
At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
>At this moment anybody who has an access to mod_perl server can read any
>data which is accessible by the same server. suexec is not an option
>because of process persistance.
I suspect this is why it is very easy to find hosting providers who
provide PHP, and not as easy to find providers who support Embperl,
Mason or other mod_perl solutions. Is there any effort to deal with
this? (Per-virtual-server-process-sharing, with the option of
dropping to zero processes, seems like a good start.) I'd really
like to see languages like Embperl stand a better chance going
head-to-head against PHP. It's very annoying to be able to whip
together a great solution for my own servers, only to have to
implement it for one of my clients in PHP, without nearly the power
that Perl gives me.
===
To: Kee Hinckley <nazgul@somewhere.com>
From: Stas Bekman <stas@stason.org>
Subject: Re: security
Date: Thu, 1 Mar 2001 17:10:44 +0800 (SGT)
On Thu, 1 Mar 2001, Gunther Birznieks wrote:
> At 10:33 PM 2/28/2001 -1000, Kee Hinckley wrote:
> >At 9:44 AM +0800 3/1/01, Stas Bekman wrote:
> > >At this moment anybody who has an access to mod_perl server can read any
> > >data which is accessible by the same server. suexec is not an option
> > >because of process persistance.
> >
> >I suspect this is why it is very easy to find hosting providers who
> >provide PHP, and not as easy to find providers who support Embperl,
> >Mason or other mod_perl solutions. Is there any effort to deal with
> >this? (Per-virtual-server-process-sharing, with the option of
> >dropping to zero processes, seems like a good start.) I'd really
> >like to see languages like Embperl stand a better chance going
> >head-to-head against PHP. It's very annoying to be able to whip
> >together a great solution for my own servers, only to have to
> >implement it for one of my clients in PHP, without nearly the power
> >that Perl gives me.
> mod_perl 2.0
>
See http://perl.apache.org/~dougm/modperl_2.0.html
===
To: Stas Bekman <stas@stason.org>
From: "Jimi Thompson" <jthompson@link.com>
Subject: Re: security
Date: Thu, 01 Mar 2001 13:48:13 -0600
Probably a stupid question, but wouldn't named virtuals solve this problem?
I'm not all that familiar with MySQL, but we have a similar set up here with
slightly different technology - Solaris, Netscape Enterprise Server, and
Oracle. I should think that you could replicate this using BSD, Apache, and
MySQL, but please don't quote me on that. Then again, we authenticate via
LDAP and some of our other parameters vary from what you have as well.
===
To: modperl@apache.org
From: Gustavo Vieira Goncalves Coelho Rios
<gustavo@ifour.com.br>
Subject: security!
Date: Thu, 01 Mar 2001 18:06:24 +0000
After some time playing with modperl, i realized some problem (that's
the way i call them) related with modperl!
By looking the way modperl works today, it's clearly it were not
desgined to SECURELY support a multi-user environment. For instance: Any
user can write a script that will be able to read any file owned by the
httpd server, in a multi-user environment it should not be allowed. A
gentle way to prevent this would be not to allow a script read a file
whose owner id is not the same from the script owner id, isn't it?
Another problem: process creation should be wrapped by apache suexec
mechanism, is it currently done this way? Why not?
************
************
May some here confirm me that if i am a security concious admin, i
should not make modperl+embperl available to my user?
************
************
====
To: Gustavo Vieira Goncalves Coelho Rios
<gustavo@ifour.com.br>
From: Vladimir Ivaschenko <hazard@hazard.maks.net>
Subject: Re: security!
Date: Fri, 2 Mar 2001 00:15:51 +0300
Take a look at http://www.freevsd.org. I haven't used it personally, but
it looks like something that you need..
This system is a based on making a chroot environment for each user with
his own apache and everything.
===
To: Vladimir Ivaschenko <hazard@hazard.maks.net>
From: clayton cottingham <drfrog@smartt.com>
Subject: Re: security!
Date: Thu, 01 Mar 2001 13:49:47 -0800
Vladimir Ivaschenko wrote:
>
> Take a look at http://www.freevsd.org. I haven't used it personally, but
> it looks like something that you need..
> This system is a based on making a chroot environment for each user with
> his own apache and everything.
>
i can vouch for this approach to development
weve been using it in house for 3 months
its so nice
multiple developers on one box!!
===
To: Gustavo Vieira Goncalves Coelho Rios
<gustavo@ifour.com.br>
From: Andrew Ho <andrew@tellme.com>
Subject: Re: [OT] security!
Date: Thu, 1 Mar 2001 15:35:05 -0800 (PST)
Hello,
GR>By looking the way modperl works today, it's clearly it were not
GR>desgined to SECURELY support a multi-user environment. For instance: Any
GR>user can write a script that will be able to read any file owned by the
GR>httpd server, in a multi-user environment it should not be allowed.
This is a general Unix webserver issue and not specific to mod_perl, so
I've marked your message [OT] for off-topic.
You cannot easily avoid this problem in general.
(1) HTTP requests can come from anybody.
(2) All HTTP requests are serviced by the same webserver.
(3) The webserver needs to be able to read and execute scripts.
Therefore, in general if untrusted users can write webserver executed
scripts, they can read anything the webserver can.
GR>A gentle way to prevent this would be not to allow a script read a file
GR>whose owner id is not the same from the script owner id, isn't it?
This is fine, but you're talking about revamping Unix permissions here,
not at the webserver level. The webserver cannot enforce this condition
because the webserver only runs the script, it is not the OS that the
script runs on.
GR>Another problem: process creation should be wrapped by apache suexec
GR>mechanism, is it currently done this way? Why not?
This could help sidestep the issue. It is not done this way by default,
because even using suexec doesn't automatically make your scripts secure,
and in fact it can make the situation worse.
GR>May some here confirm me that if i am a security concious admin, i
GR>should not make modperl+embperl available to my user?
If you are a security conscious admin, and you cannot trust your users,
you should not make mod_perl available to them. In fact you should not
make any dynamic HTTP functionality available to them--CGI, ISAPI,
FastCGI, or anything else.
===
To: modperl@apache.org
From: mgraham@circadence.ca
Subject: RE: security!
Date: Thu, 1 Mar 2001 18:55:26 -0500
> This is a general Unix webserver issue and not specific to
> mod_perl, so I've marked your message [OT] for off-topic.
Well, workarounds are available for specific webserver environments, so I
don't believe it's an inappropriate question.
With CGI, you use the suexec mechanism to start executable programs as a
particular user. AFAIK you can't impersonate a user on unixy environments
without forking a new process. And forking a new process under mod_perl
really defeats the purpose.
Plus, because it is easy to crash or stall a server running mod_perl, each
mod_perl user really needs administrative access to his or her own web
server, including the ability to stop and start it.
One method (as people have noted) is to create a number of complete virtual
chrooted unix environments, each with its own webserver.
Another is to have pools of httpds: each pool running as a different user
and listening to a unique port; then you run a proxying front-end to direct
traffic to each user's server based on hostname or whatever. Complicated,
and (I believe) quite memory-intensive.
More info is in the guide:
http://perl.apache.org/guide/multiuser.html#ISPs_providing_mod_perl_services
In mod_perl 2.0 (when it is released) you will have the opportunity
(depending on your platform) to use the hybrid process/threading model.
Then you will have a single httpd for each user, and that httpd will be able
to handle multiple requests via multiple threads. This solution could
probably be used in an ISP, to achieve the same level of user-partitioning
that is now availble under CGI via suexec.
===
To: "mgraham@circadence.ca" <mgraham@circadence.ca>
From: Matt Sergeant <matt@sergeant.org>
Subject: RE: security!
Date: Fri, 2 Mar 2001 00:08:29 +0000 (GMT)
On Thu, 1 Mar 2001, mgraham@circadence.ca wrote:
>
> > This is a general Unix webserver issue and not specific to
> > mod_perl, so I've marked your message [OT] for off-topic.
>
> Well, workarounds are available for specific webserver environments, so I
> don't believe it's an inappropriate question.
>
> With CGI, you use the suexec mechanism to start executable programs as a
> particular user. AFAIK you can't impersonate a user on unixy environments
> without forking a new process. And forking a new process under mod_perl
> really defeats the purpose.
Does it? I used to believe that too, but now that I've developed
applications that make rather extensive use of the Apache API, I would
actually love to have an environment similar to CGI but providing the full
Apache API, including logging, notes/pnotes, etc. I realise a lot of this
would be tricky and would require RPC (thus opening up a security hole in
its own right) but I think it would be worthwhile.
I certainly don't like the way we're all assuming mod_perl 2.0 is going to
solve all our problems. It won't. It will just give us some fresh ones
(like making all modules thread safe).
===
To: "modperl@apache.org" <modperl@apache.org>
From: Tom Brown <tbrown@baremetal.com>
Subject: (changing userids/2.0/suexec) was: RE: security!
Date: Thu, 1 Mar 2001 16:21:02 -0800 (PST)
> >
> > > This is a general Unix webserver issue and not specific to
> > > mod_perl, so I've marked your message [OT] for off-topic.
> >
> > Well, workarounds are available for specific webserver environments, so I
> > don't believe it's an inappropriate question.
> >
> > With CGI, you use the suexec mechanism to start executable programs as a
> > particular user. AFAIK you can't impersonate a user on unixy environments
> > without forking a new process. And forking a new process under mod_perl
> > really defeats the purpose.
changing userids has nothing to do with fork()... the problem is simply
that it requires root priviledges, and since you need to give them up
permanently if you're going to run some else's "insecure" code, that
usually means a temporary process... (which typically means fork()ing a
short lived process, so you could make the connection)...
The apache 2.0 model seems to include a mechanism for routing requests to
a group of apache child processes which have _already_ switched to the
target userid... in short, the pre-fork model is extended to have classes
of pre-forked processes... it seems to be a mightly good fix for this
particular problem.
That said, I only took about two minutes reading one of the URLs posted
earlier today, but I got that far and said "that'll work!" and quit
reading until I have time to actually test some of this ...
===
To: modperl@apache.org
From: Todd Finney <tfinney@boygenius.com>
Subject: Re: security
Date: Thu, 01 Mar 2001 17:23:49 -0500
Stas Bekman wrote:
> On Wed, 28 Feb 2001, Gustavo Vieira Goncalves Coelho Rios wrote:
> > the key user\password are kept inside this file, so anyone can uses an
> > editor to retrieve the user mysql account. I resolve this problem
> > running php on secure mode and chgrping the php file the same user as
> > the http process and removing other flags file access (g-rwx). So nobody
> > besides the owner of the file (or the http process) will be able to read
> > it.
>
> At this moment anybody who has an access to mod_perl server can read any
> data which is accessible by the same server. suexec is not an option
> because of process persistance.
>
> I understand that you want to store the SQL engine authentication info,
> and users not to know each other's access credentials. The only solution
> at this point is to either trust your users not to abuse each other, or
> run a separate server for each one :(
There is a distinct possibility that I don't understand the
problem, but couldn't you set up a db connection sub in a
file, -750 customer.nobody, like this:
sub connect {
my $r = shift; # we need a request object from somewhere
return undef unless $r->server_name eq
'www.thisvirtualhost.org';
my $db_user = 'user';
my $db_pass = 'pass';
my $db_name = 'name';
use DBI;
my $dbh=DBI->connect(mumblemumblemumble);
return $dbh;
}
You might want to think about another way of doing your
connections, anyway. If you have lots of virtual hosts,
and all of them are opening distinct connections, you're
going to run out of MySQL handles pretty quick, or choke
your server with Apache::DBI cached handles. I've heard
that you can use a single connection module which then
changes to use a specified database, but I've never tried
that myself.
===
To: modperl@apache.org
From: mgraham@circadence.ca
Subject: RE: security!
Date: Thu, 1 Mar 2001 20:03:42 -0500
> > And forking a new process under mod_perl
> > really defeats the purpose.
>
> Does it?
Well I confess I just assumed.
> I used to believe that too, but now that I've developed
> applications that make rather extensive use of the Apache API, I would
> actually love to have an environment similar to CGI but
> providing the full
> Apache API, including logging, notes/pnotes, etc.
How would it be similar to CGI then? I'm guessing you want to be able to
register a separate program to handle any part of the request phase?
> I certainly don't like the way we're all assuming mod_perl
> 2.0 is going to solve all our problems. It won't.
Well, personally, I use my own servers when I use mod_perl, so this
particular problem doesn't affect me. But I think that finding a good
ISP-friendly mod_perl solution would be good in general to help promote Perl
as a viable modern web programming language. I think that promoting perl as
a *modern* web programming language would be good for the perl community
because it would encourage more people to use modern programming practices
(strict mode, OO etc.) rather than the quick one-offs of yore that were so
popular with CGI. Not that there's anything wrong with that of course.
I know some people who run a small ISP and they would probably consider
offering a mod_perl service, if they could put a bunch of users on a box and
protect the users from each other reasonably well.
Of course, mod_perl is not the only way to promote Perl on the web, but this
is a mod_perl list :)
===