[PHP] chmod 0777 to be or not to be?

[DJMaze]

Als PHP ontwikkelaar en beveiliger zie ik steeds Joomla, YOO, WordPress, etc. ontwikkelaars op fora roepen dat chmod 0777 slecht is en daardoor de website gehacked is.

Echter even een voorbeeld:

chroot is schijnbaar de "holy grail" volgens deze mensen.
vervolgens heb je van die mensen een upload script.
In chroot modus heb je schrijftoegang tot elk bestand en map zodat je in theorie overal php bestanden kan uploaden.
Vervang via zo'n upload script de index.php en voila, de site is vervangen.

Gebruik je geen chroot (maar bijv. apache of nobody) dan heeft een php script geen schrijftoegang tenzij je die map specifiek op 0777 zet.

Dus ja, wat is nou wijsheid?

Persoonlijk geef ik het upload script de schuld want die is fout. Een php bestand mogen uploaden met een jpeg extensie en vervolgens mogen hernoemen naar ".php" is gewoon een no go.
Maar hier gaat het topic natuurlijk niet over.

Wat is nou beter: 0777 of 0755?

[RobIII]

Waar hoort mijn topic?
PRG >> NOS

[Hero of Time]

Heb je het nou over bestanden of mappen? Want een bestand heeft geen bal aan de execute bit en is voor een server totaal overbodig en een groot beveiligingsrisico. Voor mappen is soms zelfs 550 of 500 meer dan voldoende. Bestanden doet de admin vaak en is met 640 of 644 meer dan genoeg, uitgaande van root:apache rechten.

Maak je gebruik van een CMS zoals Wordpress, dan heb je maar 1 map waar Apache in mag schrijven en die stel je in op zo'n manier dat het vanaf de shell en webserver zelf niet uit te voeren is. Dus al is 't een php bestand, dat 't dan alsnog als plain text wordt behandeld, ipv de instructies in de .php uit te voeren. Maar je zorgt natuurlijk dat je alleen maar bepaalde bestandstypes mag uploaden (en dus niet een .php vermomt in .jpg).

[CAPSLOCK2000]

777 is nooit goed en eigenlijk altijd een aanwijzing dat er iemand aan het werk is die het niet helemaal snapt of liever lui dan moe is.

Ook in een chroot is het niet nodig om alles als root te doen. Je moet root zijn om een chroot in te gaan, maar daarna kun je gewoon met useraccounts werken:

code:

[root@desukarn opt]# chroot debian
(debian)root@desukarn:/# su - mail
$ whoami  
mail
$ touch /abc
touch: cannot touch `/abc': Permission denied
$ touch /tmp/abc

Chroot is geen "holy grail" want je kan er uit breken, zeker als root is dat vrij eenvoudig.
Wanneer je webapplicatie goed is ontworpen dan kan de applicatie niet uploaden naar directories die in de webroot staan en niet schrijven naar directories die wel in de webroot staan.

[Thralas]

Chrooten is in deze tijd een matig excuus voor een gebrek aan een semi/geheel gevirtualiseerde omgeving (KVM, Xen, of *shudder* OpenVZ).

Als je een veilige hostingomgeving wil dan moet je je sites uberhaupt niet op een shared host zetten (al dan niet met een kernel uit het jaar 1700).

[drm]

Ik heb setfacl wel eens als aanrader gezien. Ik heb er zelf geen ervaring mee, maar het is misschien wel de moeite waard om eens uit te vogelen.

[Verwijderd]

CAPSLOCK2000 schreef op donderdag 31 juli 2014 @ 16:58:
777 is nooit goed en eigenlijk altijd een aanwijzing dat er iemand aan het werk is die het niet helemaal snapt of liever lui dan moe is.

Dit. Precies dit. Zie je ergens chmod 777 in een tutorial? Negeer de tutorial.

drm schreef op donderdag 31 juli 2014 @ 21:10:
Ik heb setfacl wel eens als aanrader gezien. Ik heb er zelf geen ervaring mee, maar het is misschien wel de moeite waard om eens uit te vogelen.

ACL's worden in Linux distributies weinig gebruikt. Meestal is het eenvoudige security model al voldoende.

Voor webservices is de setgid bit meestal de oplossing. Veelal zal het probleem met een chown en een chmod 2770 zijn opgelost.

[serkoon]

De bestanden en directories in de webroot zouden niet schrijfbaar moeten zijn voor de applicatie, specifieke uitzonderingen daargelaten.

File uploads zou je buiten de webroot moeten opslaan en via een script aan de gebruiker moeten tonen of laten downloaden, zodat je de juiste autorisatiecontroles kunt doen en de juiste HTTP-headers mee kunt geven.

En elke (PHP)-website host je natuurlijk onder z'n eigen user, zodat sites elkaar niet in de weg kunnen zitten.