Bekijk Volledige Versie : [Apache2+PHP] Processen van de gebruiker ipv van apache
Ik loop al een jaartje of twee tegen hetzelfde probleem aan en moet concluderen dat het lijkt alsof er in al die tijd geen simpele oplossing voor is bedacht. Dit is wat ik wil bereiken:
Ik wil Apache2 met PHP5 beschikbaar stellen aan wat gebruikers
Deze gebruikers moeten PHP scripts kunnen draaien via Apache2 zónder safe_mode zodat ze bijvoorbeeld scripts kunnen starten via exec() of backticks
Deze scripts moeten niet gedraaid worden onder de standaard Apache2 user (in mijn geval www-data (Debian Sarge)) maar onder de gebruiker van wie het bestand is
Ik moet via een VirtualHost-directive in kunnen stellen waar PHP zijn sessies opslaat en waar tijdelijke bestanden komen (iedere gebruiker heeft een aparte tmp-directory)
De gebruikers moeten in staat zijn via .htaccess-bestanden bepaalde instellingen van PHP te veranderen
De laatste twee voorwaarden sluiten een CGI-oplossing al uit, leek me. Op dit forum wordt links en rechts mod_suid2 of mod_ruid geroepen, maar tegelijk ook dat ik dan functies als posix_setuid() eruit moet slopen om het veilig te laten werken.
Graag zou ik jullie suggesties horen :)
kijk eens naar suphp, http://www.suphp.org/Home.html
dit doet alles wat je wilt
kijk eens naar suphp, http://www.suphp.org/Home.html
dit doet alles wat je wilt
De laatste keer dat ik me bezig hield met suPHP was het een systeem dat de scripts via CGI aanroept en dus niet voldoet aan mijn laatste twee voorwaarden. Is dat inmiddels opgelost? :)
Nee :)
Dan ben ik benieuwd of iemand nog andere ideeën heeft ;) overigens is er niets mis met een CGI-oplossing, zolang het maar die dingen kan die ik wil :)
of gewoon toch mod_ruid gebruiken (werkt alleen op linux)?
als je een testserver hebt dan kun je er vrij mee experimenteren
en installeren is echt een eitje, ongeveer zo:
# apt-get install libcap-dev
# /usr/bin/apxs2 -a -i -l cap -c mod_ruid.c
httpd.conf: LoadModule ruid_module /usr/lib/apache2/modules/mod_ruid.so
of gewoon toch mod_ruid gebruiken (werkt alleen op linux)?
als je een testserver hebt dan kun je er vrij mee experimenteren
Dit ga ik dan ook zometeen uitproberen :) maar kennelijk is dat ook nog niet helemaal veilig, aangezien men roept dat ik dan functies als posix_setuid() eruit moet slopen aangezien je dan kennelijk met posix_setuid(0) root-rechten zou verkrijgen...
hee interessant, ga ik straks eens uitproberen (altijd leuk om je eigen testserver te hacken)
hee interessant, ga ik straks eens uitproberen (altijd leuk om je eigen testserver te hacken)
Het werkt! Dat posix_setuid(0) lijkt geen effect te hebben, ik snap niet waarom ze er op aandringen op die functie uit te schakelen.
Bij mij (Gentoo) waren alle posix functies default uitgeschakeld.
Keenondots
19/04/06, 10:05
Korte tijd terug heb ik hieronder een stukje tekst over mod_ruid gepost:
http://blog.keenondots.com/2006/03/19/using-mod_ruid-as-a-real-alternative-to-suphp-et-al/
De beveiligingsissues met mod_ruid vallen mijn inziens erg mee. Er moet eerst een buffer overflow voor httpd gevonden worden. Daarna moet er een exploit voor deze buffer overflow gemaakt worden. De exploit moet eerst 'effective capabilities' (dus daarmee Linux-only) kiezen en kan pas daarna setuid(0) doen. Dit is anders bij mod_suid2 staat me bij.
hebben jullie ook dat de standaard mod_ruid zoals bij de auteur te downloaden is, altijd alle files weer geeft, ook de files die niet world readable zijn?
ik heb daar destijds de code voor aangepast want dat vonden mijn hosting klanten namelijk niet bijster fijn...
mod_suid2 raad ik je af, mod_ruid lijkt me een betere oplossing. Ik heb wat tests gedaan tussen deze twee modules in, mod_ruid is stukken sneller.
suPHP e.d. geven alleen maar extra overhead enzo.
posix function zou ik sowieso uit php halen, niemand heeft ze nodig.
Keenondots
19/04/06, 12:01
hebben jullie ook dat de standaard mod_ruid zoals bij de auteur te downloaden is, altijd alle files weer geeft, ook de files die niet world readable zijn?
ik heb daar destijds de code voor aangepast want dat vonden mijn hosting klanten namelijk niet bijster fijn...
Nee, krijg gewoon "failed to open dir: Permission denied" tenzij ik niet begrijp wat je bedoeld. Bovendien draaien wij alle sites met open_basedir en zelfs safemode (gaat pas uit wanneer dat strikt noodzakelijk is, vrijwel nooit dus).
<? passthru('id -a'); ?> geeft:
uid=xxxxx(username) gid=xxxxx(groupname) groups=48(apache),500(webadmin)
Lijkt me logisch dat het alle bestanden weer geeft, aangezien degene die het script draait eigenaar is van die bestanden.
Ik heb wel nu sinds dat ik mod_ruid heb draaien dat enkele apache processen regelmatig op 115%(?) cpu usage blijven hangen. Het systeem werkt prima verder maar toch staat een load van 55 wat vreemd.
Keenondots
19/04/06, 12:11
Lijkt me logisch dat het alle bestanden weer geeft, aangezien degene die het script draait eigenaar is van die bestanden.
Van de eigen users wel inderdaad. Maar root root rwxr-x--- bestanden geven gewoon permission denied, zoals het moet.
Ik heb wel nu sinds dat ik mod_ruid heb draaien dat enkele apache processen regelmatig op 115%(?) cpu usage blijven hangen. Het systeem werkt prima verder maar toch staat een load van 55 wat vreemd.
Hier geen last van met Apache 2.0.x. Weet je zeker dat het mod_ruid is en niet een bepaalde site/script/mod_rewrite/whatever?
(kan nu niet testen want heb alleen gepatchte mod_ruid hier in de buurt)
het is natuurlijk het te verwachten resultaat, maar jammer is het wel want daardoor kan je geen bestanden meer onzichtbaar maken voor de buitenwereld (zoals sqlite files bijvoorbeeld)
maar goed, hier is ongeveer de code die ik in de ruid_uiiii functie heb toegevoegd, mocht iemand interesse hebben:
if (r->finfo.filetype != APR_NOFILE)
{
if (!(r->finfo.protection & APR_WREAD))
{
ap_log_error(...);
return HTTP_FORBIDDEN;
}
}
Keenondots
19/04/06, 12:38
(kan nu niet testen want heb alleen gepatchte mod_ruid hier in de buurt)
het is natuurlijk het te verwachten resultaat, maar jammer is het wel want daardoor kan je geen bestanden meer onzichtbaar maken voor de buitenwereld (zoals sqlite files bijvoorbeeld)
Het afschermen van config files, sqlite files, etc. doe je door ze buiten de webroot te houden of een .htaccess met 'deny from all' in de betreffende map te plempen.
Overigens: je patch lijkt het uitvoeren van niet word-readable scripts te voorkomen, maar doet m.i. niets aan dat een script niet-world readable bestanden kan benaderen die aan de eigen user toebehoren (moet je ook niet willen denk ik).
maar doet m.i. niets aan dat een script niet-world readable bestanden kan benaderen die aan de eigen user toebehoren
nooit meer patchen dan noodzakelijk is he :)
Keenondots
19/04/06, 13:33
nooit meer patchen dan noodzakelijk is he :)
Maar ik begrijp je verhaal over sqlite bestanden dan niet, maar misschien heb ik niet goeg gelezen.
mijn klanten willen een eenvoudige en snelle manier hebben om de buitenwereld van bepaalde bestanden af te houden, en zonder mod_ruid gaat dat met niet-leesbaar maken voor "world". je wil toch niet dat ze je database kunnen opvragen via de browser? en ja dat kan ook door het buiten de docroot te plaatsen (lastig bij bestaande scripts) en met extra directories (extra werk) en met htaccess bestanden (trager) maar dat was de vraag even niet.
Ik geef mijn gebruikers standaard een vrije docroot waarvan ze weten dat áls het in die directory staat, het mogelijk via de browser op te vragen is. Ze kunnen alle 'gevaarlijke' bestanden buiten die root plaatsen om te voorkomen dat bij een fout oid. de bestanden niet meteen beschikbaar worden via Apache2.