|
|
 |
Hoofdstuk 22. Safe Mode
The PHP safe mode is an attempt to solve the shared-server security
problem. It is architecturally incorrect to try to solve this
problem at the PHP level, but since the alternatives at the web
server and OS levels aren't very realistic, many people,
especially ISP's, use safe mode for now.
Security and Safe Mode
Tabel 22-1. Security and Safe Mode Configuration Directives | Name | Default | Changeable |
|---|
| safe_mode | "0" | PHP_INI_SYSTEM | | safe_mode_gid | "0" | PHP_INI_SYSTEM | | safe_mode_include_dir | NULL | PHP_INI_SYSTEM | | safe_mode_exec_dir | "" | PHP_INI_SYSTEM | | safe_mode_allowed_env_vars | PHP_ | PHP_INI_SYSTEM | | safe_mode_protected_env_vars | LD_LIBRARY_PATH | PHP_INI_SYSTEM | | open_basedir | NULL | PHP_INI_SYSTEM | | disable_functions | "" | PHP_INI_SYSTEM |
For further details and definition of the PHP_INI_* constants see
ini_set().
Here is a short explanation of the configuration directives.
- safe_mode
boolean
Whether to enable PHP's safe mode. Read the
Security and chapter for more
information.
- safe_mode_gid
boolean
By default, Safe Mode does a UID compare check when
opening files. If you want to relax this to a GID compare,
then turn on safe_mode_gid.
Whether to use UID (FALSE) or
GID (TRUE) checking upon file
access.
- safe_mode_include_dir
string
UID/GID checks are bypassed when
including files from this directory and its subdirectories (directory
must also be in include_path
or full path must including).
As of PHP 4.2.0, this directive can take a semi-colon separated
path in a similar fashion to the
include_path directive,
rather than just a single directory.
The restriction specified is actually a prefix, not a directory name.
This means that "safe_mode_include_dir = /dir/incl" also allows
access to "/dir/include" and "/dir/incls" if they exist. When you
want to restrict access to only the specified directory, end with a
slash. For example: "safe_mode_include_dir = /dir/incl/"
- safe_mode_exec_dir
string
If PHP is used in safe mode, system() and the other
functions executing system programs
refuse to start programs that are not in this directory.
- safe_mode_allowed_env_vars
string
Setting certain environment variables may be a potential security breach.
This directive contains a comma-delimited list of prefixes. In Safe Mode,
the user may only alter environment variables whose names begin with the
prefixes supplied here. By default, users will only be able to set
environment variables that begin with PHP_ (e.g. PHP_FOO=BAR).
Opmerking:
If this directive is empty, PHP will let the user modify ANY
environment variable!
- safe_mode_protected_env_vars
string
This directive contains a comma-delimited list of environment
variables that the end user won't be able to change using
putenv(). These variables will be protected
even if safe_mode_allowed_env_vars is set to allow to change them.
- open_basedir
string
Limit the files that can be opened by PHP to the specified
directory-tree, including the file itself. This directive
is NOT affected by whether Safe Mode is
turned On or Off.
When a script tries to open a file with,
for example, fopen or gzopen, the location of the file is
checked. When the file is outside the specified directory-tree,
PHP will refuse to open it. All symbolic links are resolved,
so it's not possible to avoid this restriction with a symlink.
The special value .
indicates that the directory in which the script is stored will
be used as base-directory.
Under Windows, separate the directories with a semicolon. On all
other systems, separate the directories with a colon. As an Apache
module, open_basedir paths from parent directories are now
automatically inherited.
The restriction specified with open_basedir is actually a
prefix, not a directory name. This means that "open_basedir =
/dir/incl" also allows access to "/dir/include" and
"/dir/incls" if they exist. When you want to restrict access
to only the specified directory, end with a slash. For example:
"open_basedir = /dir/incl/"
Opmerking:
Support for multiple directories was added in 3.0.7.
The default is to allow all files to be opened.
- disable_functions
string
This directive allows you to disable certain functions for
security reasons. It takes
on a comma-dilimited list of function names. disable_functions
is not affected by Safe Mode.
This directive must be set in php.ini For example, you
cannot set this in httpd.conf.
See also: register_globals,
display_errors, and
log_errors
When safe_mode is on, PHP checks to see
if the owner of the current script matches the owner of the file to be
operated on by a file function. For example:
-rw-rw-r-- 1 rasmus rasmus 33 Jul 1 19:20 script.php
-rw-r--r-- 1 root root 1116 May 26 18:01 /etc/passwd |
Running this script.php
<?php
readfile('/etc/passwd');
?> |
results in this error when safe mode is enabled:
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /docroot/script.php on line 2 |
However, there may be environments where a strict UID
check is not appropriate and a relaxed GID check is
sufficient. This is supported by means of the safe_mode_gid switch. Setting it to
On performs the relaxed GID checking,
setting it to Off (the default) performs
UID checking.
If instead of safe_mode, you set an
open_basedir directory then all
file operations will be limited to files under the specified directory
For example (Apache httpd.conf example):
<Directory /docroot>
php_admin_value open_basedir /docroot
</Directory> |
If you run the same script.php with this
open_basedir setting
then this is the result:
Warning: open_basedir restriction in effect. File is in wrong directory in
/docroot/script.php on line 2 |
You can also disable individual functions. Note that the disable_functions
directive can not be used outside of the php.ini file which means that
you cannot disable functions on a per-virtualhost or per-directory basis
in your httpd.conf file.
If we add this to our php.ini file:
disable_functions readfile,system |
Then we get this output:
Warning: readfile() has been disabled for security reasons in
/docroot/script.php on line 2 |
User Contributed Notes
Safe Mode |
 add a note |
jedi at tstonramp dot com
08-Sep-2001 02:17 |
|
Many filesystem-related functions are not appropriately restricted when
Safe Mode is activated on an NT server it seems. I would assume that this
is due to the filesystem not making use of UID.
In all of my
scripts, no matter WHO owns the script (file Ownership-wise) or WHO owns
the directory/file in question; both UIDs display
(getmyuid() and
fileowner()) as UID = 0
This has the rather nasty side effect of
Safe Mode allowing multiple filesystem operations because it believes the
script owner and file/dir owner are one and the same.
While this
can be worked around by the judicious application of proper filesystem
privileges, it's still a "dud" that many of Safe Mode's
securities are simply not there with an NT implementation.
|
|
devik at cdi dot cz
24-Jan-2002 11:45 |
|
Just to note, I created patch which allows VirtualHost to set User under
which all (PHP too) runs. It is more secure than safe_mode. See
luxik.cdi.cz/~devik/apache/ if you are interested
|
|
zebz at ihaveenoughspam_hotmail dot com
28-Apr-2002 03:42 |
|
All the filesystem-related functions (unlink, fopen, unlink, etc) seems to
be restricted the same way in safe mode, at least on PHP 4.2. If the file
UID is different *but* the directory (where the file is located) UID is
the same, it will work.
So creating a directory in safe mode is
usually a bad idea since the UID will be different from the script (it
will be the apache UID) so it won't be possible to do anything with the
files created on this directory.
|
|
dw at null dot ca
13-Jun-2002 10:37 |
|
You can a vhost.conf file.
<Directory
/vhosts/domain.com/httpdocs/>
php_admin_value safe_mode
0
php_admin_value open_basedir "/"
</Directory>
|
|
tom at tom420 dot com
19-Jul-2002 08:33 |
|
open_basedir only restricts file operations to files and directories under
a specified directory, but you can still user system ("vi
/home/somedir/somefile"), so safe_mode still has a place here as it
is much more restrictive then open_basedir.
Also, to reply to
someone who said that 'above' and 'below' was a matter of perspective,
sure it is. Of course, a file is not under another one, etc, it just
pointed by some inode. But in the common language we consider the root (/)
to be above everything else, and /home is below root, and /home/myfile is
below /home. There is no written standard, but most people (those I know
anyway) agree on that syntax.
|
|
|
10-Sep-2002 10:19 |
|
disk_free_space($directory) is also restricted by the safe_mode ! It can
also be completely forbidden as this would allow a script to test the
available space in order to fill it with a giant file, preventing other
scripts to use that space (notably in
"/tmp").
disk_free_space() is then informational, and this
does not prevent system quotas to limit the size of your files to a value
lower than the available free space!
Most web server admins that
propose PHP hosting, will implement quotas for your hosting account, but
also on any shared resources such as temporary folders.
|
|
|
10-Sep-2002 10:30 |
|
Some paranoid web managers also restrict the set_user_abort()
function.
This constitutes a security issue for hosted web sites,
because the hosted script cannot guarantee safe atomic operations on files
in a reasonnable time (the time limit may still be in effect):
If
set_user_abort() is disabled by the web admin, a user can corrupt the
files of a hosted web site by simply sending many requests to the PHP
script, and aborting it fast. In some cases that can be easily reproduced
after a dozen of attempts, the script will be interrupted in the middle of
a file or database update!
The only way for the hosted web site to
protect itself in this case is to use a sleep() with a random but not null
short time before performing atomic operations.
Web admins should
then definitely NOT disable the set_user_abort() function which is vital
to ensure atomic operations on hosted critical files or
databases.
Instead they should only disable the set_time_limit()
function, and set a constant but reasonnable time for any script to
complete their atomic operations.
|
|
dizzy at roedu dot net
16-Jan-2003 06:25 |
|
For people using linux there is a very nice solution to the shared server
problem. It's called vserver/ctx. Here is the URL:
|
|
Daniel
20-Jan-2003 03:51 |
|
Vserver isn't viable if you need name based hosting. Or if you don't want
to run a seperate apache for each host. In a world with unlimited IP
addresses and RAM, it would be great. I don't live in that world though.
:(
|
|
dizzy at roedu dot net
21-Jan-2003 01:03 |
|
Daniel, but who stops you of running a proxy on the one IP address you wish
name based vhosting, and configure that proxy to map hosts to private IPs
on the vhost machine. Apache, mod_rewrite with its map based lookup does
the trick.
|
|
gtg782a at mail dot gatech dot edu
26-Jan-2003 04:14 |
|
zebz: The user would not be able to create a directory outside the
namespace where he/she would be able to modify its contents. One can't
create a directory that becomes apache-owned unless one owns the parent
directory.
Another security risk: since files created by apache are
owned by apache, a user could call the fputs function and output PHP code
to a newly-created file with a .php extension, thus creating an
apache-owned PHP script on the server. Executing that apache-owned script
would allow the script to work with files in the apache user's namespace,
such as logs. A solution would be to force PHP-created files to be owned
by the same owner/group as the script that created them. Using
open_basedir would be a likely workaround to prevent ascension into
uncontrolled areas.
|
|
sj at sjaensch dot org
18-Feb-2003 12:33 |
|
safe_mode_include_dir only works when INCLUDING files, it has no effect
when you access them by other means (eg. with fopen())! Your only solution
then is to set the user or group (if safe_mode_gid is activated) of the
file to the same as the script you are executing or disable safe mode
altogether.
See bug 20054 ().
|
|
info at phpcoding dot net
08-Mar-2003 01:44 |
|
readfile() seems not always to take care of the safe_mode setting.
When
the file you want to read with readfile() resides in the same directory as
the script itself, it doesn`t matter who the owner of the file is,
readfile() will work.
|
|
gk at proliberty dot com
27-Apr-2003 09:05 |
|
The documentation on safe_mode is wrong. It says:
>When safe_mode is
on, PHP checks to see if the owner of the current script matches the owner
of the file to be operated on by a file function.
In truth, it also
checks the ownership of the current directory: directory ownership
overrides file UID - i.e., if you own the directory, your script can read
any files in the directory, regardless of file UID. Rasmus has confirmed
that this is not a bug, it is by design. The documentation should be
updated to reflect this.
|
|
|
add a note |
| |
PHP Handleiding
Functionaliteit
HTTP authenticatie met PHP
Safe Mode
Persistente Database connecties