[Apache] Rechten

[DieterVDW]

Situatie: een hostingserver die apache 1.3.31 draait.

Probleem: een gebruiker kan een script uploaden weermee hij een directory van een andere gebruiker kan listen, en bestanden van die andere gebruiker weergeven.
Dit is niet gewenst.
(Bij een forum bvb worden database wachtwoord vaak opgeslagen in een php file)

Vraag: Hoe kan ik dit voorkomen?
Ik heb al uitvoerig geexperimenteerd met suexec en FastCGI,
maar ik heb nog geen oplossing gevonden in die hoek.
Ik slaag er ook niet in om een configuratie te vinden qua rechten waardoor dit te voorkomen valt...

Er zijn wel al wat topics geweest hierover, maar daar heb ik nog geen goeie oplossing gevonden...
Kan er iemand een goeie configuratie geven?
Tnx!

[IJnte]

Misschien is het werken met HTacces bestanden een idee. In elke map kan je een htacces bestand zetten, en daarin ook de rechten declareren.

[Kogelvis]

Je geeft erg weinig informatie over de server zelf waar hij op draait etc.
maar normaliter is het zo dat apache onder nobody of www-data oid draait als jij dan je config files waar die wachtwoorden in staan chowned naar jezelf of upload als je eigen user en dan bijv. chmod naar 644 zoals veel README's van forums etc. adviseren zou het dan niet opgelost zijn?

[CyBeR]

Met suexec kan het. Je moet dan zorgen dat alleen de eigenaar en de user waaronder apache draait toegang hebben tot de directory/files.

[Kippenijzer]

Tenzij er php scripten op gezet worden, daarvoor moet je suPHP hebben, en die is iets zwaarder voor het systeem dan de normale php, en vereist wat meer configuratie om het veilig te houden, maar het lost het probleem wel op

[GlowMouse]

PHP in CGI mode draaien is oplossing één. Mogelijkheid 2 is het aanzetten van safe-mode.

Er zijn wel al wat topics geweest hierover, maar daar heb ik nog geen goeie oplossing gevonden...

Welke oplossingen werden daar gegeven? Waarom voldoen die niet?

[DieterVDW]

Kogelvis schreef op 19 augustus 2004 @ 21:46:... chmod naar 644 zoals veel README's van forums etc. adviseren zou het dan niet opgelost zijn?

Als het bestand world-readable staat, dan is het toch nog leesbaar voor iedereen?

[_-= Erikje =-_]

php in safe_mode en dan een open_basedir op de root van de vhost zetten zou het al moeten oplossen.

[DieterVDW]

Kippenijzer schreef op 19 augustus 2004 @ 21:49:
Tenzij er php scripten op gezet worden, daarvoor moet je suPHP hebben, en die is iets zwaarder voor het systeem dan de normale php, en vereist wat meer configuratie om het veilig te houden, maar het lost het probleem wel op

Liefst geen php-only oplossing, het zou moeten voor alle soorten scripts werken...

[DieterVDW]

CyBeR schreef op 19 augustus 2004 @ 21:47:
Met suexec kan het. Je moet dan zorgen dat alleen de eigenaar en de user waaronder apache draait toegang hebben tot de directory/files.

Dat klinkt inderdaad goed!
Ik ken helaas nog niet zoveel van suexec.
Werkt dat dan ook met php of moet ik dat apart regelen?

[tomato]

Ik ben niet echt een expert op het gebied van Apache configuratie, maar ik kom zo op een aantal mogelijkheden.

Met Apache 1.x:

• PHP in Safe mode
  Zou ik zelf niet zo blij mee zijn en je bent nog niet van alle problemen af (oa beperkt dit zich uiteraard tot PHP).
• suexec
  Werkt uiteraard niet voor mod_php en ik zou niet blij worden van PHP als CGI (geldt natuurlijk ook voor Perl, Python, etc).
• mod_diffprivs ?!?
  Je moet het maar vertrouwen...
• mod_become ?!?
  Idem.

Of met Apache 2:

MPM met User directives (en perchild?).

[Rac-On]

ten eerste:

Een gebruiker kan via je apache een script uploaden en uitvoeren? Ok......

Lees verder eens wat over Chroot

Daarnaast:
Als je apache de files world readable heeft, dan zijn die bestanden toch wel te zien, script of niet?
Je kan wel de default listing rechten van de www dirs uit zetten. Dat doe ik ook:
rwxr-xr-x. Op deze manier kunnen mensen wel de dir in, maar geen ls doen...

[Kogelvis]

DieterVDW schreef op 19 augustus 2004 @ 22:00:
[...]


Als het bestand world-readable staat, dan is het toch nog leesbaar voor iedereen?

hmmm daar kon je wel es gelijk in hebben

ik moet eerst beter nadenken voordat ik wat typ

[DieterVDW]

tomato schreef op 19 augustus 2004 @ 22:05:
We gebruiken dus apache 1.3.31.

• suexec
Werkt uiteraard niet voor mod_php en ik zou niet blij worden van PHP als CGI (geldt natuurlijk ook voor Perl, Python, etc).

Da's inderdaad ook een van de grootste bezwaren tegen suexec .
Daarom probeer ik momenteel FastCGI werkende te krijgen (zie ook hier), maar da's ook al geen pretje ...
Moest het werken zou het blijkbaar toch wel ideaal zijn...

[DieterVDW]

rac-on schreef op 19 augustus 2004 @ 22:12:
ten eerste:

Een gebruiker kan via je apache een script uploaden en uitvoeren? Ok......

Je weet wel wat ik bedoel .

Lees verder eens wat over Chroot

Ik weet wat chroot is ja, maar bestaat er dan ook zoiets voor apache of zo?
Nog niks over gevonden in ieder geval...
Kun je wat meer informatie geven? Ik weet nog niet onmiddellijk in welke richting ik moet verderzoeken...

Je kan wel de default listing rechten van de www dirs uit zetten. Dat doe ik ook:
rwxr-xr-x. Op deze manier kunnen mensen wel de dir in, maar geen ls doen...

rwxr-xr-x -> er staat overal x, dus mag iedereen toch listen? Foutje..?

[Verwijderd]

Apache moet altijd toegang hebben tot homedirs van gebruikers. Dus zolang je scripts blijven draaien onder de uid van apache, apache dus, of root afhankelijk van je config kunnen ze andere homedirs listen.

De enige complete oplossing daarvoor is suexec en suphp gebruiken, de eerste keer configgen kan een beetje lastig zijn afhankelijk van je distro, maar scripts worden dan gedraait onder de uid van de gebruiker, en die heeft normaal gesproken alleen toegang tot zijn eigen homedir.

Tenzij de andere homedirs world readable zijn natuurlijk.

[Rac-On]

DieterVDW schreef op 19 augustus 2004 @ 22:39:

Je weet wel wat ik bedoel .

Nee om eerlijk te zijn niet... ik denk dat je een php pagina bedoeld die vervolgens een directory listing doet?

Ik weet wat chroot is ja, maar bestaat er dan ook zoiets voor apache of zo?
Nog niks over gevonden in ieder geval...
Kun je wat meer informatie geven? Ik weet nog niet onmiddellijk in welke richting ik moet verderzoeken...

Je kan je apache chrooten, maar als meerdere gebruikers dezelfde apache gebruiken, dan heb je er niks aan..

rwxr-xr-x -> er staat overal x, dus mag iedereen toch listen? Foutje..?

[/quote]

Mijn fout en jou fout. Ik bedoelde rwx--x--x. De x heb je nodig om de bestanden in de directory te mogen 'zien'. De r heb je nodig om een listing te doen.
Op mijn webserver is mijn picture dir --x, waardoor ik wel iemand het url van een foto kan geven, maar die iemand niet door al mijn foto's kan bladeren (tenzij je brute-force namen gaat proberen).

Wat je voor je hosting kan doen:

Uploaden van bestanden via ftp. Ftp homedir per user, zodat je via de ftp nooit de dir van een andere user kan bereiken.
Voor iedere user een apparte virtual host, zodat je een doc root hebt waarmee je niet in andermans directory kan komen
Je dirs rwx--x--x maken, zodat je geen listing op kunt vragen van andermans directory.

Je bent dan redelijk safe.. ALs je verder wilt gaan, zulje me met suexec de pagina's met het userid van de betreffende user moeten laten draaien. Dat is natuurlijk de mooiste oplossing, maar ik heb er zelf geen ervaring mee...


@fabio, readable betekend niet listable!!!

[DutchTSE]

gewoon directory listing uitzette zodat je 403 krijgt als je wilt listen

(of is dit een hele domme opmerking )

[DieterVDW]

rac-on schreef op 19 augustus 2004 @ 22:55:
[...]

Nee om eerlijk te zijn niet... ik denk dat je een php pagina bedoeld die vervolgens een directory listing doet?

Ja inderdaad!
Met dat uploaden bedoelde ik gewoon dat een gebruiker een script via FTP op z'n webspace kan zetten... Doet er niet echt toe

Je kan je apache chrooten, maar als meerdere gebruikers dezelfde apache gebruiken, dan heb je er niks aan..

Idd, geen optie voor onze webserver dus...

Mijn fout en jou fout. Ik bedoelde rwx--x--x. De x heb je nodig om de bestanden in de directory te mogen 'zien'. De r heb je nodig om een listing te doen.
Op mijn webserver is mijn picture dir --x, waardoor ik wel iemand het url van een foto kan geven, maar die iemand niet door al mijn foto's kan bladeren (tenzij je brute-force namen gaat proberen).

Ik dacht dat het net omgekeerd was, maar je hebt gelijk!

Wat je voor je hosting kan doen:

Uploaden van bestanden via ftp. Ftp homedir per user, zodat je via de ftp nooit de dir van een andere user kan bereiken.
Voor iedere user een apparte virtual host, zodat je een doc root hebt waarmee je niet in andermans directory kan komen

Done...

Je dirs rwx--x--x maken, zodat je geen listing op kunt vragen van andermans directory.

Dit is niet mogelijk, want de gebruiker moet steeds in staat zijn om wél een listing van een dir te kunnen krijgen als 'm de 'Indexes' optie aanzet in een .htaccess bestand...

[riotrick]

suexec voor cgi scriptjes en open_basedir restricitie in php lost het probleem prima op. Safe mode is niet nodig in php om open_basedir te gebruiken.

[DieterVDW]

riotrick schreef op 20 augustus 2004 @ 00:39:
suexec voor cgi scriptjes en open_basedir restricitie in php lost het probleem prima op. Safe mode is niet nodig in php om open_basedir te gebruiken.

Inderdaad! Dit is de perfecte oplossing voor php!
Ik zet nu gewoon in elke virtualhost declaratie de regel:

php_admin_value open_basedir *homedir van user*

En dat lijkt te werken!

Bij suexec heb ik toch nog een paar bedenkingen:
Script files zouden moeten ge'chmod zijn naar 700, terwijl 'gewone' bestanden (html pagina's bvb) zeker niet mogen gechmod naar 700, want anders kan apache ze niet meer lezen.
Dit is een ongemakkelijke situatie, hoe moeten we dit aanpakken?
Gebruikers met aandrang vragen om hun script files te chmodden naar 700, en als ze het niet doen, pech... ?
Of een cronjob die ieder uur alle .pl en .cgi files chmod naar 700 bvb?
-> beide niet echt ideale oplossingen...

[DieterVDW]

IJnte schreef op 19 augustus 2004 @ 21:45:
Misschien is het werken met HTacces bestanden een idee. In elke map kan je een htacces bestand zetten, en daarin ook de rechten declareren.

De gebruikers hebben zelf toegang tot hun .htaccess files, dus daarin rechten declareren heeft weinig zin...

[arikkert]

beste werkt uiteindelijk toch om elke website een eigen apache webserver te geven die draait onder 1 (webmaster) user. Kost wel meer load dan virtual hosting met 1 apache, maar je kunt er aardig wat draaien op 1 machien.

[DieterVDW]

arikkert schreef op 20 augustus 2004 @ 02:02:
beste werkt uiteindelijk toch om elke website een eigen apache webserver te geven die draait onder 1 (webmaster) user. Kost wel meer load dan virtual hosting met 1 apache, maar je kunt er aardig wat draaien op 1 machien.

Mjah... Heb het ook al zitten denken...
Maar hoe gaat dat dan ivm poort 80?
Er kan toch maar 1 proces poort 80 gebruiken?

[tomato]

DieterVDW schreef op 20 augustus 2004 @ 02:25:
Maar hoe gaat dat dan ivm poort 80?
Er kan toch maar 1 proces poort 80 gebruiken?

Over het algemeen heeft iedere gebruiker dan ook een eigen IP adres en bovendien hoef je het van buiten het netwerk niet te merken als er op de fysieke webserver veel verschillende poorten worden gebruikt.

[ Voor 22% gewijzigd door tomato op 20-08-2004 03:23 ]

[Kippenijzer]

1 apacke op poort 80 met lekker veel mod_rewirte regels, dan kan idd iedere virtual host via je poort 80 mod_rewritende apache over bij (en hoef je dus ook geen poorten buiten 80 open te zetten voor het hosten).

[arikkert]

DieterVDW schreef op 20 augustus 2004 @ 02:25:
[...]


Mjah... Heb het ook al zitten denken...
Maar hoe gaat dat dan ivm poort 80?
Er kan toch maar 1 proces poort 80 gebruiken?

ik draai inderdaad niet namebased, maar ip based.
in mijn geval alle webservers draaien op poort 80 van hun eigen ip adres, dat een alias ip is van de NIC.

[igmar]

arikkert schreef op 20 augustus 2004 @ 02:02:
beste werkt uiteindelijk toch om elke website een eigen apache webserver te geven die draait onder 1 (webmaster) user. Kost wel meer load dan virtual hosting met 1 apache, maar je kunt er aardig wat draaien op 1 machien.

Per user een IP dus. Ik denk niet dat je voor deze toepassing IP's van RIPE gaat krijgen, en al helemaal niet van een ISP. MAW : geen oplossing.

[igmar]

DieterVDW schreef op 20 augustus 2004 @ 01:38:
Dit is een ongemakkelijke situatie, hoe moeten we dit aanpakken?

mod_suid, mod_become of apache 2 met een per-user MPM.

[tomato]

igmar schreef op 20 augustus 2004 @ 15:16:
mod_suid, mod_become of apache 2 met een per-user MPM.

Nadeel van (als ik het goed heb) al deze 3 is dat Apache als root moet draaien.

[igmar]

tomato schreef op 20 augustus 2004 @ 16:07:
Nadeel van (als ik het goed heb) al deze 3 is dat Apache als root moet draaien.

Dat geldt voor apache MPM zeker niet. Het nadeel daarvan is dat het slecht werkt, en dat er per vhost processen gestart worden. mod_suid vereist een recompile, maar de childs draaien wil onder een non-root user.