Teeed's Website

Zaczynając standardową propagandę…

Co to toto? suPHP pozwala na wykonywanie skryptów PHP na serwerze na prawach ich owner-a. Co to nam daje? Odpowiednio skonfigurowane zwiększa (z pozoru) bezpieczeństwo serwera, a tak naprawdę, zwiększa wygodę użytkowników…

Standardowo skrypty PHP uruchamiane są na prawach daemona WWW (w przypadku domyślnej instalacji Apache z mod_php jest to użytkownik www-data). Należy jednak pamiętać, że w tym wypadku, skrypty niezależnie, czyje są, są uruchamiane na tym samym użytkowniku.. Można zatem z powodzeniem namieszać w plikach innego użytkownika swoimi skryptami + występuje problem dot. modyfikacji plików przez skrypty www i potem użytkownik może się do nich dostać po choćby sesji FTP (która chodzi na jego użytkowniku)…

O ile do prostych zastosowań się nadaje, to nie powinno się go używać (niech broni) na serwerach produkcyjnych, gdyż jest to proszenie się o nieszczęście…

O wiele lepszym (bezpieczniejszym, szybszym itd…) rozwiązaniem byłoby uruchomienie FastCGI na prawach odpowiednich użytkowników, odpowiedni chroot, odpowiednio dobrane patche na kernel, i duuużo innych „cudów”, jednak opiszę to innym razem…

Teoria operacji

mod_suphp niestety do bezpiecznych nie należy. Używa swojej binarki suphp z setuid-em (na roocie [!] wiec bardzo nieładnie i bardzo niebezpiecznie… patche na kernel można uznać za obowiązkowe) która jest używana odpowiednio do uruchamiania skryptów…

-rwsr-xr-x 1 root root 187688 cze  4  2008 /usr/lib/suphp/suphp

Brrrr

Instalacja

Na początek sprawdźmy, co mamy w repo

teeed@teeed:~$ aptitude search mod-suphp
p   libapache2-mod-suphp                                                   - Apache2 module to run php scripts with the owner permissions

Jak widać jest to, czego szukamy, zatem przystąpmy do instalacji.

Zlom005:~# aptitude install libapache2-mod-suphp

Po skończonej instalacji przystępujemy do edycji plików konfiguracyjnych…

Zlom005:~# vim /etc/suphp/suphp.conf

Plik jest samowyjaśniający się. Jedyne czego wymaga, to podstawowej znajomości angielskiego. Przykładowy plik mógłby wyglądać choćby tak:

[global]
;Path to logfile
;Logowanie
logfile=/var/log/suphp/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=www-data

;Path all scripts have to be in
docroot=/var/www

;Path to chroot() to before executing script
;chroot=/var/www

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=true
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0077

; Minimum UID
min_uid=1000

; Minimum GID
min_gid=1000

[handlers]
;Handler for php-scripts
application/x-httpd-php=php:/usr/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

Odpalmy moduł suPHP w serwerze Apache.

Zlom005:~# a2enmod suphp

Następnie musimy udać się do edytowania VirtualHost-ów.

Zlom005:~# vim /etc/apache2/sites-enabled/somehost

Musimy pamiętać, żeby wyłączyć mod_php, gdyż inaczej mogą podziać się różne nieciekawe rzeczy.

<VirtualHost *>
...
        <Directory />
                php_flag engine off
                suPHP_engine on
        </Directory>
...
</VirtualHost>

Tym oto prostym sposobem włączyliśmy suPHP i wyłączyliśmy mod_php.

Test?

Utwórzmy plik php, najlepiej z tak, jak będzie to robił „docelowy” użytkownik. Utwórzmy zatem prosty skryptm który „wypluje” nam UID użytkownika, na którym uruchomiony jest skrypt.

<?php
echo getmyuid();

Jeżeli wypisał się dobry UID to oznacza, że nasza konfiguracja działa. Zatem możemy cieszyć się końcem problemów z FTP.

Zródła

suPHP – Home