|
|
 |
第 41章セーフモード
PHPのセーフモードは共有サーバでのセキュリティの問題を解決するための
試みです。この問題をPHPのレベルで解決しようとするのはアーキテクチャ上
正しくありません。しかし、WebサーバやOSレベルでの代替策はあまり現実的
ではないため、多くのユーザ、特にISPではセーフモードが現在使用され
ています。
表 41-1. セキュリティとセーフモード設定ディレクティブ | 名前 | デフォルト | 変更の可否 |
|---|
| 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 | | disable_classes | "" | PHP_INI_SYSTEM |
PHP_INI_*の定義と詳細については、
ini_set()を参照して下さい。
以下に設定ディレクティブに関す
る簡単な説明を示します。
セーフモードの設定ディレクティブの簡単な説明を以下に示します。
- safe_mode
boolean
セーフモードを有効にするか否か。詳細は
セキュリティの章をご覧ください。
- safe_mode_gid
boolean
デフォルトでは、セーフモードはオープンしようとするファイルの
UIDの比較チェックを行います。GIDの比較にすることでこのチェックを
緩やかなものにしたい場合、safe_mode_gidをオンにしてください。
ファイルにアクセスする際にUID (FALSE)を使用するか
GID (TRUE)を使用するか制御できます。
- safe_mode_include_dir
string
このディレクトリ（そのサブディレクトリも含む）の配下のファイルが
インクルードされる場合、UID/GID
のチェックはバイパスされます。（ディレクトリは
include_pathの配下であるか
あるいはフルパスで記述される必要があります）
PHP 4.2.0以降、このディレクティブは
include_pathと同様に
セミコロンで分けた形式で複数のパスを書くことができます。
ここで指定される制限は実はプレフィックスでありディレクトリ名ではありません。
つまり、"safe_mode_include_dir = /dir/incl" と書くと
"/dir/include" と "/dir/incls" の両方へのアクセスが許可されます（もし
ディレクトリが存在すれば）。指定したディレクトリのみを許可したい
場合には、最後にスラッシュを追加してください。
例："safe_mode_include_dir = /dir/incl/"
- safe_mode_exec_dir
string
PHPがセーフモードで動作する場合、system()や
その他のプログラム実行関数を、
このディレクトリ以外で起動することは拒否されます。
- safe_mode_allowed_env_vars
string
ある種の環境変数の設定はセキュリティ上の潜在的な欠陥となりえます。
このディレクティブにはプレフィックスをカンマで区切って書くことができます。
セーフモードでは、ここに書かれたプレフィックスで始まる環境変数だけを
ユーザーが変更できるようになります。デフォルトでは、ユーザーは
PHP_で始まる名前の環境変数(e.g. PHP_FOO=BAR)だけをセットすることができます。
注意:
このディレクティブが空の場合、PHPは全ての環境変数について
ユーザーが変更することを許可してしまいます。
- safe_mode_protected_env_vars
string
putenv()を使ってエンドユーザーが変更するのを
防ぎたい環境変数をカンマ区切りで記述します。ここで設定された環境変数は
もしもsafe_mode_allowed_env_varsでは許可されているものであっても
保護されます。
- open_basedir
string
PHPによってオープンされうるファイルを特定のディレクトリツリー
に制限します。このディレクティブはセーフモードのオン/オフに
関わらず適用されます。
例えばfopenやfzopenを使ってスクリプトがファイルをオープンしようと
するとそのファイルの位置がチェックされます。指定された
ディレクトリツリーの範囲外にあった場合、PHPはオープンを拒否します。
全てのシンボリックリンクは解決されますので、シンボリックリンクを使って
この制限を回避することは不可能です。
.は特別な値で、
スクリプトが格納されているディレクトリをbase-directoryとして
使用することを意味します。
Windows上では、ディレクトリをセミコロンで区切ってください。
その他全てのシステムでは、ディレクトリをコロンで区切ってください。
Apacheモジュールでは、親ディレクトリからopen_basedirへのパス
は自動的に継承されます。
ここで指定される制限は実はプレフィックスでありディレクトリ名ではありません。
つまり、"open_basedir = /dir/incl" と書くと
"/dir/include" と "/dir/incls" の両方へのアクセスが許可されます（もし
ディレクトリが存在すれば）。指定したディレクトリのみを許可したい
場合には、最後にスラッシュを追加してください。
例："open_basedir = /dir/incl/"
注意:
複数のディレクトリへの対応は3.0.7で追加されました。
デフォルトでは全てのファイルのオープンが許可されます。
- disable_functions
string
セキュリティを考慮したい場合に
このティレクティブを使って、特定の関数を無効にすることができます。
関数名をカンマ区切りで表記してください。disable_functionsは
セーフモードの影響を受けません。
このディレクティブは php.ini上でセットされなければなりません。
例えば、httpd.conf等でセットすることはできません。
- disable_classes
string
セキュリティを考慮したい場合に
このティレクティブを使って特定のクラスを無効にすることができます。
クラス名をカンマ区切りで表記してください。disable_classsは
セーフモードの影響を受けません。
このディレクティブは php.ini上でセットされなければなりません。
例えば、httpd.conf等でセットすることはできません。
Availability note:
このディレクティブはPHP4.3.2で追加されました。
register_globals,
display_errors,
log_errorsも参照してください。
セーフモードがonの場合、PHPは、
現在のスクリプトの所有者がファイル関数により処理されているファイル
の所有者に一致するかどうかを調べます。例えば、
-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 |
以下のscript.php を実行すると、
|
<?php
readfile('/etc/passwd');
?>
|
セーフモードが有効な場合、以下のようなエラーが出力されます。
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 |
UID checking.
しかし、多くの環境において、厳密なUIDチェックは
適切ではなく、より緩やかなGIDチェックで十分です。
これはsafe_mode_gidスイッチで
サポートされます。これをOnにすると制限の緩い
GIDチェックに、Off（デフォルト）
にするとUIDチェックになります。
safe_modeの代わりに、
open_basedirディレクトリを
セットすると、全てのファイル操作は特定のディレクトリ配下のみに制限されます。
例えば(Apacheのhttpd.confの例):
<Directory /docroot>
php_admin_value open_basedir /docroot
</Directory> |
open_basedirでセットしたのと
同じscript.phpを実行すると、以下のような結果になります:
Warning: open_basedir restriction in effect. File is in wrong directory in
/docroot/script.php on line 2 |
特定の関数を無効にすることもできます。
disable_functionsディレクティブは
php.ini以外では使用できないことに注意してください。
つまり、httpd.conf上のバーチャルホスト毎あるいはディレクトリ毎に
関数を無効にすることはできない、ということになります。
もしphp.iniファイルに以下を追加した場合:
disable_functions readfile,system |
以下のような結果になります:
Warning: readfile() has been disabled for security reasons in
/docroot/script.php on line 2 |
bertrand dot gorge at epistema dot com
23-Sep-2004 12:58
Beware that when in safe mode, mkdir creates folders with apache's UID, though the files you create in them are of your script's UID (usually the same as your FTP uid).
What this means is that if you create a folder, you won't be able to remove it, nor to remove any of the files you've created in it (because those operations require the UID to be the same).
Ideally mkdir should create the folder with the script's UID, but this has already been discussed and will not be fixed in the near future.
In the meantime, I would advice NOT to user mkdir in safe mode, as you may end up with folders you can't remove/use.
Russ
31-Aug-2004 03:52
Sometimes you're stuck on a system you don't run and you can't control the setting of safe mode. If your script needs to run on different hosts (some with safe mode, some without it), you can code around it with something like:
<?php
if( ini_get('safe_mode') ){
}else{
}
?>
daniel dot gaddis at tlc dot state dot tx dot us
17-Mar-2004 07:03
on windows if multiple directories are wanted for safe_mode_exec_dir and open_basedir be sure to separate the paths with a semi colon and double quote the whole path string. For example:
safe_mode = On
safe_mode_exec_dir = "F:\WWW\HTML;F:\batfiles\batch"
open_basedir = "F:\WWW\HTML;F:\batfiles\batch"
uuganbat at datacom dot mn
26-Feb-2004 09:32
users executing shell scripts by filename.php, and I take the server in safe mode but some things are not working on web server, and disabled functions by php.ini but the simple commands in Unix are executing how disable to execute shell scripts via *.php file.
example
<?php
echo `ls -l /etc/`; echo `more /etc/passwd`;
?>
matthias at remove-this dot hrz dot uni-kassel dot de
12-Nov-2003 05:38
Beware: Safe mode will not permit you to create new files in directories which have different owner than the owner of the script. This typically applies to /tmp, so contrary to Unix intuition, you will not be able to create new files there (even if the /tmp rights are set correctly).
If you need to write into files in /tmp (for example to put logfiles of your PHP application there) create them first on the command line by doing a
touch /tmp/whatever.log
as the same user who owns the PHP script. Then, provided the rest is configured correctly, the PHP script will be able to write into that file.
info at phpcoding dot net
08-Mar-2003 02: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.
gtg782a at mail dot gatech dot edu
26-Jan-2003 05: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.
dizzy at roedu dot net
16-Jan-2003 07: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:
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.
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.
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.
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.
devik at cdi dot cz
25-Jan-2002 12: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
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.
| |
持続的データベース接続
