Privilege separation revisited
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
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Privilege separation revisited
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: [EMAIL PROTECTED] 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
From: Joel Palmius [EMAIL PROTECTED] Date: Thu, 31 Jul 2003 11:12:02 +0200 (CEST) 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)? You don't need, parallel installations, just parallel instances. One main server running on port 80 set up to proxy requests to the relevant user's process. Individual users have their own httpd.conf set up with a unique port under a unique user (themselves, for instance). Each instance is started by simply running: $ httpd -f /path/to/that/users/httpd.conf _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
Re: Privilege separation revisited
Hello, JPThe question is, what is the state-of-the-art approach for protecting data JPwritten to a file by mod_perl from being overwritten by an untrusted user? JPIs it possible to run all mod_perl things as a separate user (without JPhaving to keep two parallel apache installations)? pYou don't need, parallel installations, just parallel instances. p pOne main server running on port 80 set up to proxy requests to the prelevant user's process. p pIndividual users have their own httpd.conf set up with a unique port punder a unique user (themselves, for instance). On an Internet exposed system you don't necessarily want to permit those httpds to run as actual users. Instead, it is probably safer to make a number of unprivileged users (www-perl, www-username, www-php, or whatever) that have no shells (or whatever other security restrictions you are interested in) and have the httpds run as them. You can put them in the same group as the related user (for example if user andrew is in group andrew, you can create a www-andrew user with no shell, but in group andrew so files can be shared). This minimizes the damage a badly written CGI can do (blow away any group writeable files in group andrew, for example, rather than blow away any of user andrew's files plus do bad stuff masquerading as user andrew). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
