Webserver med vhosts - Hvad med sikkerheden (chroot, jail, andet)

Spørgsmålet handler egenlig blot om at din PHP er sat ordenligt op.

Apache er som udgangspunkt sikker da brugere jo som bekendt ikke kan scripte sig ud af deres hjemmemappe på serveren - det skal de bruge et scriptsprog til fx PHP, eller eksempelvis CGI. De kan heller ikke bruge trailing slashes til at forsøge at få fat i filer uden for deres VirtualHost.

Hvis du bruger mod_vhosts_alias er det straks mere besværligt, da (i følgende mit nuværende kendskab) mappingen ikke bliver håndteret korrekt. Nu kan jeg ikke sige med sikkerhed at det er løst fra version 2.2 men det er værd at undesøge nærmere.

Udbydere benytter gerne følgende opsætning til PHP for at undgå at deres kunder laver rav i den:

Bestemmer open_basedir for hvert eneste "hotel".
Kører i safe_mode

Og i øvrigt handler det om at holde sine programversioner opdateret, det være sit apache og php samt disses dependencies.

Jeg kender ikke xampp, men hvis vi tager udgangspunkt i en standard VirtualHost opsætning, så kunne en godt sikret apache+php konfiguration se således ud:

<VirtualHost *:80>
    ServerName domæne.dk
    ServerAlias www.domæne.dk
    DocumentRoot /vhosts/domæne.dk
    <Directory /vhosts/domæne.dk>
        php_admin_value open_basedir "/vhosts/domæne.dk"
        php_admin_flag safe_mode 1
    </Directory>
</VirtualHost>

Tak for det.

Jeg fik vidst ikke forklaret helt præcist hvad jeg ville.
I sidste ende er det en server som skal kunne oprette vhosts via et script for, at installere et custom CMS, det skal kunne kende forskel på hvilken bruger ( get_current_user() ), der kører scriptet, så jeg har nogle variabler jeg kan bruger i min PHP til at forbinde til den rigtige database med det rigtige brugernavn og password.

Håber du kan følge mig så langt.

Som nævnt har jeg sat apache op til dynamisk vhost vha:

VirtualDocumentRoot /web/vhosts/%0/www

Så umiddelbart kan jeg jo ikk styre <Directory> direktivet direkte for hver vhost? Eller er der en smart måde at tilføje nye VirtualHosts på?

Jeg ønsker ikke at køre safe_mode i php da det begrænser for mange funktioner, som jeg ved jeg skal bruge senere hen.

Jeg er faldet over suPHP som burde kunne gøre hvad jeg har brug for. Nu skal jeg bare finde ud af hvordan jeg kører PHP5 som et CGI-modul..

Jeg har selv rodet med vhost_alias med henblik på at have en automatisk konfiguration, men jeg indså hurtigt at en række problemer med den funktionalitet ville gøre den mere besværlig at bruge end en standard VirtualHost opsætning pr. hotel.

En mulighed for at gøre konfigurationen semi-automatisk er at bruge Include i apache konfigurationen, på følgende måde:

Include /etc/httpd/conf/sites/*.conf

I biblioteket /etc/httpd/conf/sites/ ville der så ligge en .conf fil for hvert hotel med et <VirtualHost> direktiv.

Mappen kunne fx indholde en række filer ala:

/etc/httpd/conf/sites/domæne1.conf
/etc/httpd/conf/sites/domæne2.conf
osv.


En helt anden mulighed er at bruge fx Perl til at skrive en, dog stadig semi-automatisk, konfiguration direkte i Apache konfigurationen med et <Perl> direktiv med mod_perl og evt. mod en MySQL database.

Fælles for dem begge, og egenlig det der gør dem, i mine ord, semi-automatiske, er at de kræver at Apache genstartes. Det lyder måske som en utrolig bøvet manøvre at måtte gøre for hver gang der er ændringer i konfigurationen, men jeg vil vædde med at de fleste udbydere i en eller anden form benytter sig af den model. Omvendt kan de også bestemme hvornår de skal foretage de nye ændringer, modsat en on-the-fly handling foretaget via en hjemmeside.

Personligt er jeg af den overbevisning at sætte en webserver op med de faciliteter du efterspørger, generelt kræver en bred teoretisk ballast. Jeg har selv brugt umådeligt timer på at "tweake" Apache i forskellige retninger, og det tager tid inden alt falder på plads.


Nu skriver jeg videre på dette indlæg mens jeg har set dit sidste indlæg omkring suPHP.

Jeg tror ikke suPHP løser alle dine problemer - det vil blot introducere nogen andre.

Hvis du får det til at virke, må du meget gerne i det omfang du kan, forklare hvad du har gjort for at sætte det op - suPHP er stadig et eksternt modul, som benytter en langsom php-cgi fortolker, og tilmed under udvikling. Alene af den sidstnævnte grund ville jeg aldrig implementere den i et produktionsmiljø.

Samtidigt varetager suPHP en opgave der egenlig hører hjemme under Apacheserveren - det er ikke fortolkersproget opgave at sørge for at scripts bliver afviklet under ejerens brugernavn.

Tak for tippet ang. Include /etc/httpd/conf/sites/*.conf - Var ikke klar over man kunne anvende asterix på den måde i apaches config-filer.

Jeg har pt. en resellerkonto hos site5 (www.site5.com) og de kører PHP5 som et CGI modul, og umiddelbart vil jeg ikke klage over hastigheden på deres servere.

Du skriver at suPHP varetager en opgave, som apache egentlig burde tage sig af. KAN den dét? Så man slipper for suPHP (Det virker besværligt, og som du siger er det "forkert") Eller snakker vi om engang i fremtiden? Jeg kører pt. Apache 2.2.3.

Som nævnt tidligere kan man styre hvilke mapper i systemet apache har adgang til vha <Directory> direktivet. Men det forhindrer jo desværre ikke en bruger i at rode i andres mapper, da der også er specificeret adgang til disse - Så umiddelbart kan jeg kun konkludere at det på en eller anden måde skal køre under en unik bruger for hver vhost?

Tak for gode svar.

Hvis du kører Apache 2.2 får du et problem med at bruge suPHP:
http://www.suphp.org/FAQ.html


Apache-folket er i gang med (eller har vist udvilket) et modul der for hver request til serveren afvikler denne i en seperat thread (eller noget der hen af) og således under en bestemt systembrugers id - og i såfald vil PHP script blive afviklet af en systembruger og ikke af brugeren "apache" eller "www", og sikkerheden vil til følge blive forøget.
Problemet er så vidt jeg forstår at dette modul stadig er på forsøgsbasis og ikke er garenteret stabilt.

Det bedste du kan gøre er at skrive en VirtualHost og dertilhørende Directory blok for hvert hotel du skal hoste og skrive som minimum open_basedir ind for hver brugers mappe. Så kan de fra PHP kun få fat i deres egne filer, og ikke kommer længere ud i filsystemet. Dog skal du huske på at når du ikke kører PHP i safemode, kan der være et sikkerhedsaspekt mht. exec() funktionen m.fl.
Kan brugerne fx have success med følgende på et ikke-safemode setup?

echo exec('cat /etc/passwd');

Jeg kunne ikke lige finde noget om det, men det ville være en god idé at undersøge. I øvrigt er jeg i tvivl mht. hvad du mener med safemode, om du har behov for at det er slået fra eller om dine kunder har behov for at have det slået fra - for i så fald ville jeg mener jeg at der er tale om et så løst setup at det næsten skriger på et virtuel operativ system for hvert "hotel".

Som sagt, hvis du opsætter din apache for hvert "hotel" som 10/11-2006 10:43:48, med en VirtualHost og Directory, så er setup'et ret sikkert, og i min mening ville det skyldes huller i softwaren, hvis der ville opstå et hack.

Kører man ikke i safe_mode, kan man med exec / backticks via PHP, tilgå resten af systemet.

Jeg vil lige undersøge om vores applikation kan køre i safe_mode (Jeg mener bl.a. at det besværliggører filuploads via PHP? Men det er der sikkert en smart workaround til)

Vender lige tilbage med svar når jeg ved noget mere.

Umiddelbart ser det ud som om, at jeg godt kan overleve med safe_mode til :)

Jeg har lavet dette script til at oprette nye vhosts på maskinen (account.create.sh):

#!/bin/bash
#
# Parameters:
# 1. Domain
# 2. Password
#
# Create dirs and copy files as root
mkdir -p /web/vhosts/$1
echo Created /web/vhosts/$1

cp -r /web/skeleton/* /web/vhosts/$1
echo Copied skeleton

# Add user to system
useradd -g vhosts -p $2 $1
echo Created user: $1

# Chown permissions
chown -R $1:vhosts /web/vhosts/$1
echo chowned /web/vhosts/$1 to $1:vhosts
chmod 1777 /web/vhosts/$1/tmp
echo Chmodded /web/vhosts/$1/tmp to make it writable


# Canvas specific - Allows fileuploads
chmod 1777 /web/vhosts/$1/www/canvas/MediaLibraryFiles
echo Chmodded /web/vhosts/$1/www/canvas/MediaLibraryFiles to make it writable

# Add vhost to apache
echo "<VirtualHost *:80>
    ServerName $1
    ServerAlias www.$1
    DocumentRoot /web/vhosts/$1/www
    <Directory /web/vhosts/$1>
        php_admin_flag safe_mode 1
    php_admin_value open_basedir \"/web/vhosts/$1\"
    php_admin_value tmp_upload_dir \"/web/vhosts/$1/tmp\"
    php_admin_value session.save_path \"/web/vhosts/$1/tmp\"
    </Directory>
</VirtualHost>" > /opt/lampp/etc/sites/$1.conf
echo "Created vhost in apache"

# Reload config
/opt/lampp/lampp reload

----------------------------------------------

get_current_user()-funktionen i PHP returnerer ikke hvilken bruger scriptet kører under, men derimod ejeren af scriptet, så i og med at jeg har chown'ed vhost-mappen til en bruger kan jeg bruger denne funktion til at få brugernavnet på domænet, og dermed tildele en bestemt database med unikt brugernavn osv i mine scripts.

Det eneste jeg skal have fikset nu er, at når man opretter filer via PHP (Filuploads, fopen osv) så bliver det gjort i apaches brugernavn (Nobody:Nogroup) og det er selvfølgelig ikke optimalt.

Man kunne selvfølgelig køre et cronjob hver x. minut, men jeg vil mene at dette belaster serveren unødvendigt, og hvis jobbet kører midt i nogle filuploads bliver rettighederne inkonsistente indtil jobbet kører næste gang - Så det er absolut ikke optimalt.

Noge idéer til hvordan jeg kommer rundt om dette?

Efter at man har uploadet en fil, kører man chown() på den fra PHP.

Men det er netop her balladen opstår: Fordi php scripts bliver afviklet under apache-serverens bruger-id, vil de filer og mapper der bliver oprettet gennem fx PHP, blive ejet af apache.

Alternativet til dette er at bruge et CGI program, kombineret med Apache suExec, til at håndtere filuploadingen - der er ingen der har sagt at det skulle være nemt at sætte en Apache-server op :)

Har du fundet en løsning?