Privilege separation revisited

[Joel Palmius <jo...@mh.se>]

This is something I asked before, like one or two years ago. I just want 
to see if a solution has come up since then.

The problem is that with the normal (linux-distro) installation of apache 
and mod_perl, all processes for all active scripting (cgi, perl, PHP..) 
run as the same user. Thus, if I run a mod_perl app which keeps a data 
repository in a file, then that file need to grant write permissions to 
the web user. If there are untrusted users with access to PHP on the 
system, then this becomes a problem, since they could easily overwrite 
that file with a simple script. 

One may ask why untrusted users should have access to PHP, but this is
often the case with student servers in academics, specifically in computer
science.

The question is, what is the state-of-the-art approach for protecting data 
written to a file by mod_perl from being overwritten by an untrusted user? 
Is it possible to run all mod_perl things as a separate user (without 
having to keep two parallel apache installations)?

  // Joel

Re: Privilege separation revisited

["Mike P. Mikhailov" <mi...@sibtel.ru>]

Hello Joel Palmius,

Thursday, July 31, 2003, 3:12:02 PM, you wrote:

JP> This is something I asked before, like one or two years ago. I just want 
JP> to see if a solution has come up since then.

JP> The problem is that with the normal (linux-distro) installation of apache 
JP> and mod_perl, all processes for all active scripting (cgi, perl, PHP..) 
JP> run as the same user. Thus, if I run a mod_perl app which keeps a data 
JP> repository in a file, then that file need to grant write permissions to 
JP> the web user. If there are untrusted users with access to PHP on the 
JP> system, then this becomes a problem, since they could easily overwrite 
JP> that file with a simple script. 

JP> One may ask why untrusted users should have access to PHP, but this is
JP> often the case with student servers in academics, specifically in computer
JP> science.

JP> The question is, what is the state-of-the-art approach for protecting data 
JP> written to a file by mod_perl from being overwritten by an untrusted user? 
JP> Is it possible to run all mod_perl things as a separate user (without 
JP> having to keep two parallel apache installations)?

Not sure what you meant about 'two parallel apache installations' but
anyway. We have real working internet solution which I think safe
enough. Even we do not use any content generating approaches
other than mod_perl I think our solution will work with them.

We have one DSO (linux) manually compiled apache whith two (actually
more) config files (DSO to avoid two binaries). One for external
proxy-cache apache. And one or more for internal real working-horse apaches.
We start external proxy to serve static content and dispatch requests
to the internal processes which serves dynamic content (we call it application
servers). Proxy run under nobody and application server run under user
which has enough rights to open/read/write private resources. Usually this is
normal OS user and application server has ServerRoot=$HOME of this
user. So with backend app server no priviledges conflict and resources
is not world writable. Proxy listen internet connections and app
servers has no access from internet.

Actually things more complicated, but I thik I was clear in our
approach.

-- 
WBR, Mike P. Mikhailov

mailto: mike@sibtel.ru
ICQ:    280990142

You're much more likely to be knocked down by a snowball than by an equivalent number of snowflakes.

Re: Privilege separation revisited

[Stas Bekman <st...@stason.org>]

Joel Palmius wrote:
> This is something I asked before, like one or two years ago. I just want 
> to see if a solution has come up since then.
> 
> The problem is that with the normal (linux-distro) installation of apache 
> and mod_perl, all processes for all active scripting (cgi, perl, PHP..) 
> run as the same user. Thus, if I run a mod_perl app which keeps a data 
> repository in a file, then that file need to grant write permissions to 
> the web user. If there are untrusted users with access to PHP on the 
> system, then this becomes a problem, since they could easily overwrite 
> that file with a simple script. 
> 
> One may ask why untrusted users should have access to PHP, but this is
> often the case with student servers in academics, specifically in computer
> science.
> 
> The question is, what is the state-of-the-art approach for protecting data 
> written to a file by mod_perl from being overwritten by an untrusted user? 
> Is it possible to run all mod_perl things as a separate user (without 
> having to keep two parallel apache installations)?

That would be possible with mod_perl 2.0, when Apache releases the perchild 
mpm. Since at this moment nobody seems to be interesting in finishing it off, 
I can't tell you when it's going to be available. If you have tuits to 
complete it (there is a working prototype) email the httpd-dev list. 
Alternatively you may want to sponsor one of the developers to do the work.

For more information see:
http://httpd.apache.org/docs-2.0/mod/perchild.html

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com