|
|
 |
Chapter 25. Installed as an Apache module
When PHP is used as an Apache module it inherits Apache's user
permissions (typically those of the "nobody" user). This has several
impacts on security and authorization. For example, if you are using
PHP to access a database, unless that database has built-in access
control, you will have to make the database accessible to the
"nobody" user. This means a malicious script could access and modify
the database, even without a username and password. It's entirely
possible that a web spider could stumble across a database
administrator's web page, and drop all of your databases. You can
protect against this with Apache authorization, or you can design
your own access model using LDAP, .htaccess files, etc. and include
that code as part of your PHP scripts.
Often, once security is established to the point where the PHP user
(in this case, the apache user) has very little risk attached to it,
it is discovered that PHP is now prevented from writing any files
to user directories. Or perhaps it has been prevented from accessing
or changing databases. It has equally been secured from writing
good and bad files, or entering good and bad database transactions.
A frequent security mistake made at this point is to allow apache
root permissions, or to escalate apache's abilities in some other
way.
Escalating the Apache user's permissions to root is extremely
dangerous and may compromise the entire system, so sudo'ing,
chroot'ing, or otherwise running as root should not be considered by
those who are not security professionals.
There are some simpler solutions. By using
open_basedir you can control and restrict what
directories are allowed to be used for PHP. You can also set up
apache-only areas, to restrict all web based activity to non-user,
or non-system, files.
User Contributed Notes
Installed as an Apache module
phil at NOSPAM dot blisswebhosting dot com
26-Mar-2005 12:32
To Pollox and anyone else considerig using "open_basedir" without safe mode.
Open_basedir does NOT protect against this:
<?
exec("/usr/bin/cat /etc/passwd",$output);
var_dump($output) ;
?>
outputting the password file (which is world readable)
or
<?php
exec("/bin/ls -lhaR /") ;
?>
recursively outputting your filesystem.
ANY system comand can be run through the exec and system function as the apache user. Safe mode and it's family of configuration options are the ONLY way to protect against this.
mike w
04-Jan-2005 02:17
fyi, an alternative to the perchild mpm exists that I think works much better. It still requires a proccess for each vhost, but in many cases that is a small price to pay for the huge gains in security.
muxmpm/metuxmpm for apache 2
The Metux MPM is an module for the Apache 2.0 Webserver which allows it to run several VirtualHosts under different User-IDs. Some other modules such as mod_cgid allow functionality which is superficially similar. Metux MPM allows you to control the process' user IDs from the central configuration, on the basis of individual or multiple VirtualHosts directives.
Metux MPM is a project evolution from the perchild module included in the offical Apache 2 distribution. Where perchild was has somewhat languished and many bugs remain unfixed, the Metux MPM has been furiously advancing its development toward a stable release.
NOTE: This does not work with mod_ssl. I run a patched metuxmpm version of apache 2 for my vhosts on port 80 and a seprate apache2 install for mod_ssl.
official site: http://www.metux.de/mpm/
Download and instructions: http://www.sannes.org/metuxmpm/
tifkap
01-Mar-2004 06:21
There is a safe way to support a lot of users in a secure way, without having to use CGI, in a way which is probebly faster
than mod_php.
Use FastCGI, with the SuExecWrapper set to your suid wrapper. It means every user wil get his own program-group, with processes
which are being reused. If the numer of processes that is being
started on startup is 0, then the processgroup for a user will be generated when needed.
This means: The first page is slow, after that the Zend Engine caching kicks in. When the load on the virtualhost reduces, the
processes wil die off, and extra processes for a user-process-group
will only be started when (again) needed.
Your apache will be a LOT! lichter, because it won't have to drag all
the php-memory overhead with it. This means static content is
faster, and the whole system uses less memory.
The PHP itself also won't need to drag along the apache overhead.
If for one reason or the other php craches, your apache will simple
start some new php-processes. If you want to upgrade/patch php,
you can simple create the new fastcgi binary, and after testing, you can simple update the system by copying it, and maybe doing a
'apachectl gracefull'
In short : Sepparating distinct functions in different processes
communicating useing IPC methodes can be very good
for performance and security. The best example of this
principle at work is Postfix, where every process runs
chroot() under its own uid.
http://wiki.openisis.org/i/view/Php/HowtoFastCgi
Georgee at CWC
30-Apr-2003 09:16
Additional CAUTION to anyone trying Pollux's solution:
It's kind a good. Probably works right. I think I'll give it a try myself. BUT...
its safe ONLY on the assumption that apache is 100% CLEAN. (codes and confs.) Any flaws on apache, almost ANYTHING could happen to ALL users -precisely, web users. (Because apache is a member of ALL -again, web user's- GID.) So, leeps's hint should be one of the important things.
There is nothing close to perfect. What I wrote is just one thing you'll have to keep in mind. So, consider carefully BEFORE you try this solution. (Well, this applies to any other solutions though...)
rbemrose at vgmusic dot com
23-Mar-2003 09:03
In response to MartinPierre,
open_basedir doesn't require Safe Mode to be on. Have you tried using it instead of Safe Mode?
As Daniel has shown above, open_basedir can be set by VirtualHost, Location, or Directory and only affects the scripts within those areas.
MartinPierre
17-Mar-2003 12:45
Just removing the read right for Directories will not solve all the problems :
If the user is using a well-known PHP Application which always stores it's database password in a well known file, it is easy to deduct the name of the file !!
As for Safemode, it disables features that are required for several programs.
The only solution for the PHP module, would be to support Suexec, which could be made optional...
But at least, *nix installtion COULD be made more secure...
I know I certainly use suexec for Perl, but the only way to do so for PHP is running it as a CGI, which is not a practical solution...
leeps
10-Mar-2003 08:59
@pollux: additionally, tell your users to set their file-permissions to
- r-- (group) for files
- --x (group) for directories.
this disables the webserver to browse user's directory. if you don't know the filename, you cannot open it, e.g. by running malicious php-code through one of the users scripts.
Pollux
09-Mar-2003 12:38
Well, is this the solution?
I have a server with many VHosts. PHP runs in safemode as an Apache-Module. Using suexec, CGIs are generally run under UID of the VHost. PHP is configured on a per-VHost-basis to let people open only their own files:
php_admin_value open_basedir "/home/username/"
And now the best: Apache runs as user wwwrun and this user is member of all groups, that every vhost is. So nothing needs to be world-readable to be accessed by Apache. Therefore, other users can't read your php-files by CGI and even not by shell-access!
What do you think?
qdk at amok dot dk
23-Dec-2002 07:45
As far as i can tell the perchild MPM of Apache 2 is crap, due to the fact that you need to run at least 1 process for each vhost, with a "normal" MPM like worker og prefork there will default be spawned 5 servers, using the same amount with the perchild MPM and hosting 2000 vhosts you would have 10000 process running just starting the server :( furthermore you need 2 * 2000 lines you userid assignment. :(
daniel dot eckl at gmx dot de
08-Aug-2002 07:16
There is a better solution than starting every virtual host in a seperate instance, which is wasting ressources.
You can set open_basedir dynamically for every virtual host you have, so every PHP script on a virtual host is jailed to its document root.
Example:
<VirtualHost www.example.com>
ServerName www.example.com
DocumentRoot /www-home/example.com
[...]
<Location />
php_admin_value open_basedir \ "/www-home/example.com/:/usr/lib/php/"
</Location>
</VirtualHost>
If you set safe_mode on, then the script can only use binaries in given directories (make a special dir only with the binaries your customers may use).
Now no user of a virtual host can read/write/modify the data of another user on your machine.
Windseeker
forster at nospam dot verplant dot org
02-Aug-2002 08:08
Apache2 comes with an MPM (Multi Processing Module) which allows for UIDs being assigned to vhosts. This means that all PHP requests will be served under the UID assigned to the vhost.
The module is not currently running under all OSes, so I'm afraid windows folks are left out once again.. The name of this gimmick is "perchild" (or "mpm_perchild_module") and comes with Apache2. You can't imagine how easier this feature made my life :)
de dot uxp at anthem dot BACKWARDS
22-Jul-2002 10:50
In response to xwolf@xwolf.de
>On bigger sites, users for virtual not
>only have ftp / scp, but also access
>to the filesystem.
Well - If chrooting is cool and stuff.. why don't you chroot your users ?
Give them a /dev/null+zero, /bin/bash+cat+ldconfig+ls , /etc/group+ld.so.cache+localtime+passwd+profile, /lib/ld-linux+libc+lidl+libhistory+libncurses+libnss+libreadline and all additional tools you think they might need (vi or whatever)
Granted - this is some work to do. But you only have to do it once. Works for me. Not chrooting your users is IMO a lack in security, too.
xwolf at xwolf dot de
08-Jul-2002 06:32
In response to rick@brainscraps.com:
Your comment to hallow@webmages.com shows a lack of understanding into the problem.
Safe mode helps only for users with access by ftp or content-managers, which allow access in defined directories only.
On bigger sites, users for virtual not only have ftp / scp, but also access to the filesystem.
Due to the fact, that php-files dont get chroot'ed by suexec and mostly the users are not part of the webservers unix-group, php-files have to be global readable.
THIS is a lack in security, cause now everyone with access to the filesystem may read php-files from other virtual domains.
Safe mode doesnt help here.
If php would support suexec, people could give read-rights to theirself only. But php don't care about suexec.
Therefor php IS bad for virtual hosting WITH many different users.
Please do some research before posting misleaded opinions like yours above, because
they can mislead new PHP users. Running under CGI is the only solution to get a bit more security on systems with access to the filesystem for users.
rick at brainscraps dot com
15-Mar-2002 04:14
In response to "hallow@webmages.com":
Isn't that what Safe Mode is designed for? Read the comments under the Safe Mode section in php.ini, Then look at the doc_root and user_dir directives.
Also, read http://www.onlamp.com/pub/a/php/2001/03/29/php_admin.html
Please do some research before posting opinions like yours above, because they can mislead new PHP users. Running under CGI is not the only solution, or even the best one, as it opens up all kinds of other thorny issues.
hallow at webmages dot com
11-Jul-2001 08:54
mod_php is bad for virtual hosting. If you've got 5 different vhosts running on apache, and mod_php installed, and each of the users have some page that requires php to write something to the disk, and they give proper permissions for the web server to do so, anyone with access to php/the web server can do so.
Also, if their application has a config file which is blocked say by .htaccess, that contains things like database logins and passwords, etc., it must be readable by the web server, and as such anyone with access to write a php script can grab a copy of the file off the disk and display it.
The only way to get around this is to run a seperate instance of apache for each virtual server, or to use the php-cgi binary and something like apache's suEXEC.
| |
Case 4: PHP parser outside of web tree