[Apache 2 & PHP4] PHP onder eigen gebruiker uitvoeren

[Snow_King]

Hallo,

Ik ben sinds kort overgestapt op Apache 2.0.49 aangezien deze het ondersteund om
php als module te draaien en deze toch onder de gebruiker uitvoeren van wie het php bestand is.

Ik bouw mijn Virtual hosts als volgt op:

code:

NameVirtualHost 192.168.1.4
<VirtualHost 192.168.1.4>
    VirtualDocumentRoot /var/www/%2+/%1 
    ServerName duck.ath.cx
</VirtualHost>

Ik heb dus niet voor elke website die ik heb draaien een aparte virtual host en dat wil ik zo laten.

Nu heb ik onder Apache 1.3.29 suPHP gedraaid, maar deze had de volgende nadelen:
• trager door CGI uitvoering
• geen mogelijkheid om php_admin_value te gebruiken in de httpd.conf
• geeft soms onverklaarbare problemen

Nu is er ook mod_suid alleen is mij hiervan dus niet helemaal duidelijk of deze met Apache 2.0.49 werkt.

Het gevaarlijke aan mod_suid vind ik alleen dat je Apache als root moet draaien, dit brengt toch aardig wat risiso's met zich mee.

In Apache 2.0.49 kan je wel voor elke virtual host een eigen gebruiker geven waaronder alles moet worden uitgevoerd, maar dat wil ik dus niet.

Ik wil dat uit wordt gelezen wie de eigenaar van het bestand is en dat dan onder die gebruiker de php wordt uitgevoerd.

Bij Apache 2.0.49 kom je dus uit op deze mod: http://httpd.apache.org/docs-2.0/mod/perchild.html

Maar je moet dus geven onder welke gebruiker het moet draaien en dat wil ik dus juist "dynamisch" laten gebeuren.

Wie kan me een schopje in de juiste richting geven?

Ik draai overigens Debian 3.0, Apache is via apt-get binnen gehaald.

[ Voor 4% gewijzigd door Snow_King op 15-05-2004 19:24 ]

[igmar]

[quote]Snow_King schreef op 15 mei 2004 @ 19:24:

Nu is er ook mod_suid alleen is mij hiervan dus niet helemaal duidelijk of deze met Apache 2.0.49 werkt.

Nope, en dat gaat voorlopig ook niet veranderen.

Het gevaarlijke aan mod_suid vind ik alleen dat je Apache als root moet draaien, dit brengt toch aardig wat risiso's met zich mee.

Starten als root, de childs draaien gewoon onder de standaard apache user. Er zijn extra risico's, maar die zijn vergelijkbaar met de Apache 2 perchild.

In Apache 2.0.49 kan je wel voor elke virtual host een eigen gebruiker geven waaronder alles moet worden uitgevoerd, maar dat wil ik dus niet.

...

Maar je moet dus geven onder welke gebruiker het moet draaien en dat wil ik dus juist "dynamisch" laten gebeuren.

Dat kan met Apache 2 niet standaard. Ik heb nog geen Apache 2 modules gezien die de functionaliteit bieden, maar dat ik ze niet ken wil niet zeggen dat ze er niet zijn

[Verwijderd]

Ik heb sinds kort phpwrapper ontdekt, ik gebruik het met Apache 1.3.26 geen idee of het met 2.x werkt. Is wel via CGI maar werkt hier foutloos. En minder restricties dan suPHP. En ook vrij eenvoudig te installeren.


http://ward.webfx.be/projects.php?id=2

[Snow_King]

Mja, maar toch weer CGI en dan heb je de mogelijkheid van php_admin_value niet..

[igmar]

Waarom moet het Apache 2 zijn ? Die biedt weinig voordelen tov 1.3, en voordat 2.x een beetje volwassen is zijn we wel wat jaartjes verder denk ik.

[Snow_King]

Ik had dus gehoopt dat Apache 2.0 hier een uitkomst bood, maar dat bleek niet zo te zijn.

Vandaar dat ik 2.0 ben gaan draaien.

Het enige nadeel aan jouw mod vind ik dat je zelf moet gaan hercompilen en dat bij apt-get upgrade apache dus niet wordt meegenomen.

[igmar]

Snow_King schreef op 17 mei 2004 @ 09:57:
Het enige nadeel aan jouw mod vind ik dat je zelf moet gaan hercompilen en dat bij apt-get upgrade apache dus niet wordt meegenomen.

Daar is helaas weinig aan te doen, al is het maken van een .deb wel vrij simpel.

[Snow_King]

Klopt, apt-get source en dan is het ook een kwestie van files aanpassen.

Ik ga er eens mee testen.

[Snow_King]

Ok, tis een oude thread schoppen, maar een nieuwe thread heeft geen zin hiervoor.

Na googlen blijkt mod_suid toch erg onveilig te zijn doordat je door lekken in Apache commando's als root zijnde kan uitvoeren.

Maar toch wil ik de php onder de eigen gebruiker laten uitvoeren, waarom?
- Scripts kunnen 700 worden gechmod om zo elkaars SQL pass niet uit te kunnen lezen
- Als bijv een gallery een map aanmaakt is deze ook van jou en kan je hem zelf via de FTP verwijderen, anders is ie van www-data en dat ben jij weer niet.

Nu is er dus suPHP en mod_suid.
suPHP: Traag door CGI exec en ondersteund php_admin_value en php_flag niet
mod_suid: sneller dan suPHP, maar is onveilig door het draaien van de Apache als root.

Er is ook nog mod_become van Snert, maar die doet het zelfde als mod_suid en is daarbij ook onveilig.

Wat is hier nu aan te doen?

[igmar]

Snow_King schreef op 01 juni 2004 @ 11:39:
Na googlen blijkt mod_suid toch erg onveilig te zijn doordat je door lekken in Apache commando's als root zijnde kan uitvoeren.

Dat is absoluut geen stelregel, en een stuk FUD.

Nu is er dus suPHP en mod_suid.
suPHP: Traag door CGI exec en ondersteund php_admin_value en php_flag niet
mod_suid: sneller dan suPHP, maar is onveilig door het draaien van de Apache als root.

Er is ook nog mod_become van Snert, maar die doet het zelfde als mod_suid en is daarbij ook onveilig.

mod_suid is afgeleid van mod_become.

Wat is hier nu aan te doen?

Weinig, andere mogelijkheden zijn er niet, op apache 2 MPM na.

[Snow_King]

igmar schreef op 01 juni 2004 @ 12:07:
[...]


Dat is absoluut geen stelregel, en een stuk FUD.


[...]


mod_suid is afgeleid van mod_become.


[...]


Weinig, andere mogelijkheden zijn er niet, op apache 2 MPM na.

Hoe bedoel je stuk FUD?

[igmar]

Snow_King schreef op 01 juni 2004 @ 12:25:
Hoe bedoel je stuk FUD?

Dat een eventueel probleem in Apache dan meteen tot een root exploit zou leiden : Dat is pertinent onjuist. Je moet een x aantal calls uitvoeren wil je uberhaupt een process krijgen met root rechten, en dat vereist wel enige kunde.

[Snow_King]

Ja, maar het is dus wel mogelijk en zoals je in de README zegt: "If you want a secure system dont use this module"

Dat verontrust me een beetje

[igmar]

Snow_King schreef op 01 juni 2004 @ 18:26:
Ja, maar het is dus wel mogelijk en zoals je in de README zegt: "If you want a secure system dont use this module"

Dat verontrust me een beetje

Dat is zo met alle processen die met root privs lopen, mod_become en suPHP zijn geen uitzondering. Apache 2 MPM werkt op een andere manier, die in principe iets veiliger is. Als dat geen optie is vrees ik dat je een probleem hebt