PDA

Bekijk Volledige Versie : [Apache2+PHP] Processen van de gebruiker ipv van apache



JeRa
18/04/06, 21:45
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 :)

sander
18/04/06, 21:58
kijk eens naar suphp, http://www.suphp.org/Home.html

dit doet alles wat je wilt

JeRa
18/04/06, 22:31
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? :)

gjtje
18/04/06, 22:32
Nee :)

JeRa
18/04/06, 22:38
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 :)

t.bloo
18/04/06, 23:04
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

JeRa
18/04/06, 23:25
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...

t.bloo
18/04/06, 23:48
hee interessant, ga ik straks eens uitproberen (altijd leuk om je eigen testserver te hacken)

JeRa
19/04/06, 03:05
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.

gjtje
19/04/06, 09:07
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.

t.bloo
19/04/06, 11:49
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...

Wido
19/04/06, 11:55
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)

gjtje
19/04/06, 12:05
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?

t.bloo
19/04/06, 12:29
(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).

t.bloo
19/04/06, 13:29
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.

t.bloo
19/04/06, 13:47
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.

JeRa
19/04/06, 14:22
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.