Onderwerp: apache per user?

Er zijn meerdere mod_suid achtige modules beschikbaar.

mod_suid2 dropt permanent de priveleges van het Apache (child) process dat het request afhandelt.
Dit heeft het voordeel dat het hiermee niet mogelijk is root privileges terug te krijgen met posix_setuid(0) of soortgelijke constructies.
Het grote nadeel is dat het Apache process niet voor andere requests te hergebruiken is. Per request wordt een nieuw process gebruikt en weer gestopt, wat de performance niet ten goede komt.

Dan zijn er nog een aantal modules die alleen tijdelijk de effectieve privileges droppen, zodat het process hergebruikt kan worden voor andere requests.
Leuk voor statische bestanden, maar op het moment dat je met PHP setuid() achtige functies uitvoert kan je inderdaad root privileges krijgen.

Ook bij mod_ruid worden de privileges slechts tijdelijk verandert.
Hierbij wordt de mogelijkheid om setuid() te gebruiken echter tijdelijk uit- en aangeschakelt met Linux capabilities.
Gezien je met pure PHP code geen capabilities kan veranderen, is dat redelijk veilig.
Maar vraag me af of je niet met de dl() functie alsnog code kan laden die wel misbruik van deze capabilities kan maken. Niet uitgeprobeert verder.

Nuttige info maxnet!

Ik zal een dezer dagen eens een testje schrijven in C.

Edit: oh, toch maar meteen:

Code:

#include <iostream>

int main() {
        printf("Content-Type: text/html; charset=ISO-8859-1\n");
        printf("\n");
        setuid(0);
        printf("<p>uid: %i</p>\n", getuid());
}

... geeft als output keurig het goede uid, en niet 0. Ook setuid naar andere userid's van bestaande users werkt schijnbaar niet.

Nog meer suggesties?

Oorspronkelijk geplaatst door Stefan Mensink

...

Setuid bit wel gezet?

Oorspronkelijk geplaatst door Stefan Mensink

geeft als output keurig het goede uid, en niet 0. Ook setuid naar andere userid's van bestaande users werkt schijnbaar niet.

Dat klopt. De capabilities worden niet geerft indien je een ander proces opstart met system().

Ik doelde meer op het schrijven van een PHP module in de trend van:

cap_t cap;
cap_value_t capval[3];

cap=cap_get_proc();
capval[0]=CAP_SETUID;
capval[1]=CAP_SETGID;
cap_set_flag(cap,CAP_EFFECTIVE,2,capval,CAP_SET); /* zet de mogelijkheid om setuid() uit te voeren weer aan */

setuid(0);

De php module laad je vervolgens met de dl() PHP functie.
De dl() functie laad de library in het Apache/mod_php process, dat eerder de bevoegdheid is gegeven om capabilities te gebruiken, en niet in een apart process zoals met system/exec.
Althans dat is mijn theorie, ik moet het nog een keer uitproberen.

Okay maxnet. Da's een goeie. CGI is dus in elk geval safe. In PHP kan je functies zoals dl() uitzetten (die is toch deprecated). Desalniettemin zou ik het graag nog eens testen. Vanavond echter niet meer ;-)

Voor de compleetheid heb ik nog even getest met de volgende cgi:

Code:

#include <iostream>
#include <sys/capability.h>

int main() {
        cap_t cap;
        cap_value_t capval[3];

        cap=cap_get_proc();
        capval[0]=CAP_SETUID;
        capval[1]=CAP_SETGID;
        cap_set_flag(cap,CAP_EFFECTIVE,2,capval,CAP_SET); /* zet de mogelijkheid om setuid() uit te voeren weer aan */

        printf("Content-Type: text/html; charset=ISO-8859-1\n");
        printf("\n");
        setuid(0);
        printf("<p>uid: %i</p>\n", getuid());
}

Te compilen met: g++ -l cap test.cc

Oorspronkelijk geplaatst door TSG-Hans

Setuid bit wel gezet?

Natuurlijk niet. Met de setuid bit op zijn plaats maakt het niet uit wat voor apache eromheen hangt. Dan werkt-ie gewoon, en dat lijkt me ook wel de bedoeling. Gelukkig kunnen gewone users die bit niet setten, anders zou het wel heel gauw een zooitje worden.

Oorspronkelijk geplaatst door Stefan Mensink

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.

Dit heb ik getest met mod_suid 1.2, mod_ruid werkt het inderdaad niet bij.

Oorspronkelijk geplaatst door Wido

Dit heb ik getest met mod_suid 1.2, mod_ruid werkt het inderdaad niet bij.

Ah okay.

De bedoeling van mod_ruid is bij mij namelijk de veiligheid te verhogen, en niet om meer risico's te lopen.

Even zelf getest.

Apache 2 + mod_ruid + mod_php + dl() = zoals verwacht root toegang.
Gebruikte source beschikbaar op: http://www3.servertje.net/ruid/

Oorspronkelijk geplaatst door maxnet

Even zelf getest.

Apache 2 + mod_ruid + mod_php + dl() = zoals verwacht root toegang.
Gebruikte source beschikbaar op: http://www3.servertje.net/ruid/

Hij failed hier op sys/capability.h. Is dit een onderdeel van libpcap ?

Oorspronkelijk geplaatst door rayden

Hij failed hier op sys/capability.h. Is dit een onderdeel van libpcap ?

Nee, van libcap (zonder p): http://ftp.kernel.org/pub/linux/libs...vs/kernel-2.4/

Die wordt ook door mod_ruid gebruikt, dus als het goed is staat hij al op je systeem geinstalleerd.

Inderdaad, hier ook root via de test.php van maxnet.

In php.ini staat nu:
enable_dl = Off
disable_functions = dl (en nog enkele andere functies)

Zou dit voldoende zijn om gaten te voorkomen, of zijn er nog meer pitfalls? Andere modules bijv. waarmee risico's aanwezig zijn? Hoe hebben jullie dit opgelost?

Oorspronkelijk geplaatst door Stefan Mensink

Inderdaad, hier ook root via de test.php van maxnet.

In php.ini staat nu:
enable_dl = Off
disable_functions = dl (en nog enkele andere functies)

Zou dit voldoende zijn om gaten te voorkomen, of zijn er nog meer pitfalls? Andere modules bijv. waarmee risico's aanwezig zijn? Hoe hebben jullie dit opgelost?

Welke andere functies heb je er nog meer instaan om te disablen?

EDIT:
Hier ook root, (mod_suid, Apache 1.3.x)

De vraag is natuurlijk waarom 'normale gebruikers' compilers kunnen gebruiken..
Hier dus geen root op die manier - gebruik overigens geen mod_ruid.

Oorspronkelijk geplaatst door PeterT

De vraag is natuurlijk waarom 'normale gebruikers' compilers kunnen gebruiken..
Hier dus geen root op die manier - gebruik overigens geen mod_ruid.

Static compilen op een andere server die overeenkomt met jou server libs..is best te doen en daarna uploaden.. tadaa

Oorspronkelijk geplaatst door rayden

Welke andere functies heb je er nog meer instaan om te disablen?

disable_functions = exec,shell_exec,passthru,system,dl

Maar het zou kunnen zijn dat ik voor gebruikers enkele van die functies weer aanschakel, mocht dat gewenst zijn.