Onderwerp: apache per user?

Origineel geplaatst door lunatis
Ah ja dat is juist.
Maar moet ik dat dan enkel doen voor wget, telnet en gcc?
Waarschijnlijk ook voor cat en head en tail en weet ik veel wat nog allemaal?

Ja, cat e.d. kan je ook doen ja.

Je moet nu ook alle homedirs van users 700 chmodden, zo kunnen mensen nooit in elkaars mapje kijken.

Inderdaad, dat was de bedoeling om het op 700 te kunnen zetten, en dat ook via php geuploade bestanden de juiste owner hebben.
Nu nog eens kijken welke bestandjes enkel root mogen uitvoeren, wellicht alles dat iets naar stdout teruggeeft, of dat bestanden kan openen en zo.

Bedankt voor de reacties allemaal!

Peter

schopje.

Heeft iemand dit al eens geprobeerd? Ik was er voor de gein eens naar aan het kijken en ik loop tegen deze error aan:

FATAL: Error inserting lsm_rsuid (/lib/modules/2.6.17-1.2141_FC4/kernel/security/lsm_rsuid.ko): Invalid argument

Iemand suggesties?

Oorspronkelijk geplaatst door Wido

Je moet Apache starten als root

Als er dus een veiligheidslek zit in Apache, dan ben je flink de klos, aangezien Apache dan onder "root" draait. Met PHPsuexec heb je dit niet, aangezien Apache dan onder user "nobody" runt.

Oorspronkelijk geplaatst door dreamhost_nl

Als er dus een veiligheidslek zit in Apache, dan ben je flink de klos, aangezien Apache dan onder "root" draait. Met PHPsuexec heb je dit niet, aangezien Apache dan onder user "nobody" runt.

met phpSuExec lever je wel flink wat functionaliteit in.

Daarnaast draait met iets als mod_suid alles onder die gebruiker, dus kan je elke file, elke map 700 als chmod geven.

Tja, je moet wel iets als RSBAC, SELinux of grsec gebruiken, maar dat moet je eigenlijk altijd al doen

Oorspronkelijk geplaatst door Wido

met phpSuExec lever je wel flink wat functionaliteit in.

Daarnaast draait met iets als mod_suid alles onder die gebruiker, dus kan je elke file, elke map 700 als chmod geven.

Tja, je moet wel iets als RSBAC, SELinux of grsec gebruiken, maar dat moet je eigenlijk altijd al doen

Ik zit er nu naar te kijken, maar..eh..dat mod_suid (of mod_beocme w/e) ziet er gewoon erg lijp uit. op de RSBAC site kan ik ook niet zoveel vinden over het disablen van setuidcalls etc.

Limit je via RSBAC alleen bepaalde setuid calls naar b.v. root? of stel je gewoon voor het apache process restricties in ? van 'alleen in /home' toegang?

Alvast bedankt voor je input

Oorspronkelijk geplaatst door Wido

met phpSuExec lever je wel flink wat functionaliteit in.

Elk voordeel heeft zijn nadeel Overigens valt dat "flink" best wel mee...

Oorspronkelijk geplaatst door Wido

PHP draait als module IN httpd, httpd kan su'en, dus als jij via php setuid(); kan uitvoeren kan je setuid(0); doen.

Welnee! Een suid vanaf een userid!=0 naar 0 werkt niet zondermeer!

Bovendien, apache doet altijd een setuid, alleen dan naar user www, nobody, zoiets... De mod_?uid* modules doen precies hetzelfde, maar dan per zone, en pas zodra er een request komt ipv bij het opstarten.

In feite is voornoemde ook het risico. Om per request een setuid() te kunnen doen moet het hoofdproces als root draaien. Dat betekent dus dat requests geparsed worden als root, en als iemand in een request een bufferfout kan manipuleren, dan zou je potentieel het haasje zijn.

Oorspronkelijk geplaatst door Stefan Mensink

Welnee! Een suid vanaf een userid!=0 naar 0 werkt niet zondermeer!

Bovendien, apache doet altijd een setuid, alleen dan naar user www, nobody, zoiets... De mod_?uid* modules doen precies hetzelfde, maar dan per zone, en pas zodra er een request komt ipv bij het opstarten.

In feite is voornoemde ook het risico. Om per request een setuid() te kunnen doen moet het hoofdproces als root draaien. Dat betekent dus dat requests geparsed worden als root, en als iemand in een request een bufferfout kan manipuleren, dan zou je potentieel het haasje zijn.

Ok, tot zover had ik het ook door Dus als er b.v. een lek zou zijn in je mod_ssl / frontpage / e.d. iets anders wat je draait dan ben je gelijk ook het haasje..

Maar hoe zit het nu met de dingen IN de scripts? Op de mod_suid pagina word beweert dat ook alleenstaande PHP/Perl scripts setuid(); kan doen. Nu moet ik toevoegen dat mijn (scriptting) kennis op PHP/Perl niet zo groot is dus hoe willen ze nu dan dergelijke scripts setuid(); laten doen? Van perl weet ik dat het mogelijk is maar heo zit het b.v. met PHP?

Je moet de posfix functies in PHP uitzetten, als die aan staan kan je namelijk switchen naar root toe, anders dan Stefan zegt, ik heb het namelijk zelf getest

Ok..en hoe geld dat voor Perl? Volgens mij is het echt bijna onmogelijk om het 'zomaar' te restricten!

Ik denk dat RSBAC/GRSEC toch wel gewenst is imho..

Oorspronkelijk geplaatst door rayden

Ok..en hoe geld dat voor Perl? Volgens mij is het echt bijna onmogelijk om het 'zomaar' te restricten!

weleens aan suexec gedacht?

of..
rm /path_naar_perl ;-)

Oorspronkelijk geplaatst door rayden

Ok..en hoe geld dat voor Perl? Volgens mij is het echt bijna onmogelijk om het 'zomaar' te restricten!

Ik denk dat RSBAC/GRSEC toch wel gewenst is imho..

Perl wordt geforked, die draait dan buiten Apache als normale gebruiker, die heeft dan geen suid() rechten meer.

Okay Iedereen bedankt tot zover! Ik ga er eens mee knutselen

Oorspronkelijk geplaatst door Wido

Je moet de posfix functies in PHP uitzetten, als die aan staan kan je namelijk switchen naar root toe, anders dan Stefan zegt, ik heb het namelijk zelf getest

Hoe test je dat dan als ik het vragen mag?

Ik heb het ook getest. Eerst doe ik in het PHP-script posix_setuid(0) (of een ander uid) en dan zaken als: passthru('whoami'); of een dir op bepaalde locatie, of afgeschermde files openen... alles is dan nog keurig volgens de geselecteerde userid.

Een voorbeeldscriptje die dit 'lek' bevestigt zou welkom zijn.

Trouwens, apache heeft niet het suid-bit qua file permissions. Maar omdat deze vanaf root komt dan die naar users toe suid'en. Andersom bij mijn weten niet.

Edit: PS: Ik gebruik mod_ruid in bovenstaand voorbeeld.