Funkcje ograniczane/wyłączone w trybie bezpiecznym

Last updated: Fri, 22 Aug 2008

Tryb bezpieczny

Spis treści

Funkcje ograniczane/wyłączone w trybie bezpiecznym

Tryb bezpieczny (ang. safe mode) jest próbą rozwiązania problemów bezpieczeństwa na współdzielonym serwerze. Co prawda rozwiązywanie ich na poziomie PHP nie jest najlepszym rozwiązaniem, ale jeśli nie ma możliwości zrobienia tego na poziomie serwera www lub systemu operacyjnego, na wielu serwerach, zwłaszcza u usługodawców internetowych, używa się trybu bezpiecznego.

Ostrzeżenie

Tryb bezpieczny został usunięty w PHP 6.0.0.

Zabezpieczenia i tryb bezpieczny

**Dyrektywy konfiguracyjne zabezpieczeń i trybu bezpiecznego**
Nazwa	Wartość domyślna	Możliwość zmian	Rejestr zmian
safe_mode	"0"	PHP_INI_SYSTEM	Usunięta w PHP 6.0.0.
safe_mode_gid	"0"	PHP_INI_SYSTEM	Dostępna od PHP 4.1.0. Usunięta w PHP 6.0.0.
safe_mode_include_dir	NULL	PHP_INI_SYSTEM	Dostępna od PHP 4.1.0. Usunięta w PHP 6.0.0.
safe_mode_exec_dir	""	PHP_INI_SYSTEM	Usunięta w PHP 6.0.0.
safe_mode_allowed_env_vars	"PHP_"	PHP_INI_SYSTEM	Usunięta w PHP 6.0.0.
safe_mode_protected_env_vars	"LD_LIBRARY_PATH"	PHP_INI_SYSTEM	Usunięta w PHP 6.0.0.
open_basedir	NULL	PHP_INI_ALL	PHP_INI_SYSTEM w PHP < 6.
disable_functions	""	tylko `php.ini`	Dostępna od PHP 4.0.1.
disable_classes	""	tylko `php.ini`	Dostępna od PHP 4.3.2.

Aby zapoznać się ze szczegółami i znaczeniem stałych PHP_INI_* zobacz ini_set().

Oto krótkie wyjaśnienie dyrektyw konfiguracji.

safe_mode boolean

Określa czy należy włączyć w PHP tryb bezpieczny.

safe_mode_gid boolean

Domyślnie tryb bezpieczny sprawdza, czy właścicielem uruchamianego skryptu lub pliku, do którego funkcja chce uzyskać dostęp, jest ten sam użytkownik (UID). Jeśli chcemy aby porównywana dotyczyły całej grupy (GID), należy włączyć safe_mode_gid. Określa czy używać UID (FALSE) lub GID (TRUE) podczas sprawdzania dostępu do pliku.

safe_mode_include_dir string

Sprawdza czy nie nastąpiło obejście UID/GID podczas dołączania plików z tego katalogu i jego podkatalogów (ścieżka do katalogu powinna być podana w include_path lub też powinna być dołączona pełna nazwa ścieżki).

Od PHP 4.2.0 ta dyrektywa może zawierać dwukropek (w Windows średnik) oddzielający ścieżki, podobnie jak w przypadku dyrektywy include_path, a nie tylko pojedyńczy katalog. Rejestrowanie ścieżki określane jest obecnie przez przedrostek, a nie nazwę katalogu. To oznacza, że "safe_mode_include_dir = /dir/incl" pozwala uzyskać dostęp do "/dir/include" i "/dir/incls" (jeżeli istnieją). Gdy chcemy ograniczyć dostęp tylko do określonego katalogu, dodajemy na końcu ukośnik. Na przykład: "safe_mode_include_dir = /dir/incl/" Jeśli wartość dyrektywy jest pusta, to żadne pliki - inne niż należące do UID/GID nie mogą być dołączone (w PHP 4.2.3 i od PHP 4.3.3). We wcześniejszych wersjach mogły być dołączane wszystkie pliki.

safe_mode_exec_dir string

Jeśli PHP działa w trybie bezpiecznym, system() i inne funkcje wykonujące programy systemowe otrzymają odmowę uruchomienia programów, tych które nie znajdują się w tym katalogu. Używamy / jako separatora katalogu dla wszystkich środowisk, włącznie z Windows.

safe_mode_allowed_env_vars string

Ustawienie pewnych zmiennych środowiskowych może być potencjalnym naruszeniem bezpieczeństwa. Ta dyrektywa zawiera listę przedrostków oddzielonych przecinkami. W trybie bezpiecznym użytkownik może wyłącznie zmieniać zmienne środowiskowe, których nazwy zaczynają się od przedrostków tutaj wymienionych. Domyślnie użytkownicy mają tylko możliwość ustawiania zmiennych środowiskowych zaczynających się od PHP_ (np. PHP_FOO=BAR).

Informacja: Jeśli ta dyrektywa jest pusta, PHP pozwoli użytkownikowi zmieniać WSZYSTKIE zmienne środowiskowe!

safe_mode_protected_env_vars string

Ta dyretywa zawiera listę zmiennych środowiskowych oddzielonych przecinkami, których użytkownik końcowy nie może zmienić za pomocą putenv(). Te zmienne są zawsze chronione nawet jeśli safe_mode_allowed_env_vars pozwala na ich zmianę.

open_basedir string

Ograniczenie dla plików polegające na tym, że mogą one być otwierane przez PHP wyłącznie w określonem drzewie katalogów. Działanie tej dyrektywy NIE zależy od tego czy tryb bezpieczny jest włączony czy wyłączony.

Gdy skrypt próbuje otworzyć plik za pomocą np. fopen() lub gzopen(), sprawdzana jest lokalizacja tego pliku. Jeśli plik znajduje się poza określonym drzewem katalogów, wtedy PHP odmówi dostępu do otwarcia go. Wszystkie dowiązania symboliczne są sprawdzane, tak więc nie jest możliwe obejście tej restrykcji za pomocą dowiązań symbolicznych. Jeśli plik nie istnieje wówczas dowiązanie symboliczne nie może być sprawdzone, a pełna ścieżka nazwy pliku jest porównywana z open_basedir .

Specjalna wartość . wskazuje, że roboczy katalog skryptu ma być traktowany jako katalog podstawowy. To jest jednakże nieco niebezpieczne, jako że katalog roboczy skryptu można łatwo zmienić za pomocą chdir().

W httpd.conf, open_basedir może być wyłączony (np. dla niektórych hostów wirtualnych) ten sam efekt uzyskamy za pomocą innej dyrektywy konfiguracyjnej: "php_admin_value open_basedir none".

W Windows oddzielamy katalogi za pomocą średnika, natomiast we wszystkich innych systemach operacyjnych za pomocą dwukropka. Gdy PHP działa jako moduł serwera Apache, ścieżki open_basedir z katalogów nadrzędnych są automatycznie dziedziczone.

Restrykcja określona za pomocą open_basedir jest obecnie przedrostkiem a nie nazwą katalogu. To oznacza, że "open_basedir = /dir/incl" pozwala uzyskać dostęp do "/dir/include" i "/dir/incls" (jeżeli istnieją). Gdy chcemy ograniczyć dostęp tylko do określonego katalogu, dodajemy na końcu ukośnik. Na przykład: "open_basedir = /dir/incl/"

Domyślnie PHP ma dostęp do plików we wszystkich lokalizacjach.

disable_functions string

Ta dyrektywa pozwala nam wyłączyć pewne funkcje dla zwiększenia bezpieczeństwa. Zawiera ona listę nazw funkcji oddzielonych przecinkami. disable_functions nie zależy od trybu bezpiecznego. Ta dyrektywa musi być ustawiona w php.ini Nie można jej ustawić np. w httpd.conf.

disable_classes string

Ta dyrektywa pozwala nam wyłączyć pewne klasy dla zwiększenia bezpieczeństwa. Zawiera ona listę nazw klas oddzielonych przecinkami. disable_classes nie zależy od trybu bezpiecznego. Ta dyrektywa musi być ustawiona w php.ini Nie można jej ustawić np. w httpd.conf.

Informacja: Availability note
Ta dyrektywa została dodana w PHP 4.3.2

Patrz także: register_globals, display_errors, i log_errors.

Gdy opcja safe_mode jest włączona, PHP sprawdza czy właścicielem wykonywanego skryptu jest właściciel pliku, na którym chce operować funkcja, lub czy jest to katalog tego samego użytkownika. Na Przykład:

-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

Uruchomienie script.php:


<?php
 readfile('/etc/passwd');
?>

zwraca błąd jeśli tryb bezpieczny jest włączony:

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

Jednakże mogą być środowiska, gdzie zbyt restrykcyjna weryfikacja UID nie jest stosownym rozwiązaniem, a łagodniejsze sprawdzanie GID jest w pełni wystarczające. Można to zmienić za pomocą safe_mode_gid. Ustawienie tej opcji na On włącza łagodniejsze sprawdzanie GID, a ustawienie na Off (domyślnie) przełącza na sprawdzanie UID.

Jeśli zamiast safe_mode ustawiamy katalog open_basedir wtedy wszystkie operacje na plikach będą ograniczone do plików znajdujących się w nim. Na przykład (Apache httpd.conf):

<Directory /docroot>
  php_admin_value open_basedir /docroot
</Directory>

Jeśli uruchominy plik script.php z ustawieniem open_basedir wówczas otrzymamy wynik:

Warning: open_basedir restriction in effect. File is in wrong directory in
/docroot/script.php on line 2

Możemy wyłączyć obsługę wybranych funkcji. Zauważmy, że dyrektywa disable_functions nie może być ustawiana poza plikiem php.ini co oznacza, że nie możemy wyłączyć funkcji dla wybranego wirtualnego hosta lub katalogu zdefiniowanego w pliku httpd.conf. Jeśli dodamy następującą dyrektywę do naszego pliku php.ini:

disable_functions = readfile,system

Otrzymamy następujący wynik:

Warning: readfile() has been disabled for security reasons in
/docroot/script.php on line 2

Ostrzeżenie

Naturalnie restrykcje PHP nie obowiązują w plikach wykonywalnych.

Funkcje ograniczane/wyłączone w trybie bezpiecznym

Stałe połączenia z bazami danych

Last updated: Fri, 22 Aug 2008

add a note User Contributed Notes
Tryb bezpieczny

Anonymous
19-Aug-2008 09:09


If you do it right, you dont have to use safemode on iis.



Running as an anonymous user will make it possible to restrict (on ntfs) access everywhere you dont want users/scripts to read from.

or the other way: permit access to the http-root-HDD (in my case) or directory and deny the rest.



wanting users not be able to access the other one's dir will either require you to use for every user another "website" or safemode (which is easier to do).



so based on your security needs you know what todo:P

Anonymous
22-Jan-2008 06:29


The location of the php.ini file is documented here:



http://www.php.net/manual/en/configuration.php



I agree that a hyperlink somewhere on the page would not be out of place.

scott at ahtenindustries dot com
15-Jan-2008 09:50


It would be nice if the documentation actually specified where the php.ini file is located.

14-Sep-2006 01:18


Each IIS server in Windows runs as a User so it does have a UID file ACLs can be applied via a Group (GID) or User.  The trick is to configure each website to run as a distinct user instead of the default of System.

martin at example dot com
01-Nov-2005 07:07


On the note of php security 



have a look at: http://www.suphp.org/Home.html



 suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.

hunter+phpnet at spysatcentral dot net
08-Aug-2005 01:25


I use mkdir just fine. You just have to make sure you set sticky bits on the directory you are creating the files in. Look at "man chmod" clipping: 



4000    (the setuid bit).  Executable files with this bit set will run with effective uid set to the uid of the file owner. Directories with this bit set will force all files and sub-directories created in them to be owned by the directory owner and not by the uid of the creating process, if the underlying file system supports this feature: see chmod(2) and the suiddir option to mount(8).

mordae at mordae dot net
18-Jul-2005 10:19


It is possible to patch PHP/4 so it checks if just any directory in path is owned by proper user, e.g.

/home/mordae/www/dir/file

(where /home/mordae/www is mine and dir and file Apache's) will be readable if proper permissions set.

Read more at http://titov.net/safemodepatch/

jo at durchholz dot org
18-Jul-2005 04:18


Note that safe mode is largely useless. Most ISPs that offer Perl also offer other scripting languages (mostly Perl), and these other languages don't have the equivalent of PHP.

In other words, if PHP's safe mode won't allow vandals into your web presence, they will simply use Perl.

Also, safe mode prevents scripts from creating and using directories (because they will be owned by the WWW server, not by the user who uploaded the PHP script). So it's not only useless, it's also a hindrance.

The only realistic option is to bugger the Apache folks until they run all scripts as the user who's responsible for a given virtualhost or directory.

03-May-2005 12:37


To separate distinct open_basedir use : instead of on , or ; on unix machines.

plyrvt at mail dot ru
29-Apr-2005 06:14


[In reply to jedi at tstonramp dot com]

Safe mode is used "since the alternatives at the web server and OS levels aren't very realistic". Manual says about UNIX OS level and UNIX web-servers by design (Apache). It's not realistic for unix-like server, but for NT (IIS) each virtual host can run from different user account, so there is no need in Safe Mode restrictions at all, if proper NTFS rights are set.

bertrand dot gorge at epistema dot com
23-Sep-2004 08: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 11: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 

// Check for safe mode

if( ini_get('safe_mode') ){

    // Do it the safe mode way

}else{

    // Do it the regular way

}



?>

daniel dot gaddis at tlc dot state dot tx dot us
17-Mar-2004 02: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 04: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 12: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 09: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 12: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 02: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: http://www.solucorp.qc.ca/miscprj/s_context.hc

10-Sep-2002 06: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 06: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 04: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 11: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
24-Jan-2002 07: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
07-Sep-2001 10: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.

add a note

Funkcje ograniczane/wyłączone w trybie bezpiecznym

Stałe połączenia z bazami danych

Last updated: Fri, 22 Aug 2008