Multi-user, multi-sites: hoe rechten regelen?

[mithras]

Mijn bedrijf beheert een server waar we de projecten van klanten op hosten (webapplicaties, vps met volledige controle). Het is een nette LAMP-server en we willen kijken of we het eens goed kunnen inrichten:

1. Applicaties staan in /var/www/PROJECT_NAAM
2. Er zijn (uiteraard) meerdere projecten
3. Apache draait onder www-data, projecten zijn losse vhosts
4. Meerdere werknemers moeten bestanden binnen projecten kunnen aanmaken/wijzigen
5. Alles te bereiken met ssh/sftp

Het probleem is nu dat 1) www-data de bestanden moet kunnen lezen en 2) verschillende mensen aan bestanden "klooien". Hoe is dit op te lossen? Liever zien we niet één algemeen account, omdat het (in mijn ogen) de veiligheid niet ten goede komt.

Als ik sftp en een project upload, kan werknemer #2 een bestand niet aanpassen omdat het van mij is. Tevens moet ik zorgen dat (binnen en buiten de webroot) mappen schrijfbaar zijn voor Apache, wat ik liever doe met chown dan een directory op 777 zetten. Wat is voor deze werkwijze een goede aanpak?

[lamko]

Ik zelf zat te denken aan een script die alles goed zet of er moet hier iemand een beter idee hebben.

[deadinspace]

mithras schreef op zaterdag 02 april 2011 @ 13:22:
Het probleem is nu dat 1) www-data de bestanden moet kunnen lezen en 2) verschillende mensen aan bestanden "klooien". Hoe is dit op te lossen? Liever zien we niet één algemeen account, omdat het (in mijn ogen) de veiligheid niet ten goede komt.

Dat is een situatie waar de standaard Unix permissies niet goed in voorzien. Er zijn verschillende manieren waarop je daar een beetje omheen kunt werken (zie bv dit topic), maar ik denk dat je het beste af bent met ACLs. Het zal even wat moeite kosten om ze door te krijgen, maar daar kun je wel een degelijke oplossing mee maken.

Mijn ervaring met ACLs is ongeveer 0, maar ik vermoed dat iets als dit voor een webroot een aardige stap in de goede richting zou moeten zijn:

# file: /srv/www/project1
# owner: root
# group: root
user::rwx
group:rwx
group:www-data:r-x
group:project1:rwx
mask::rwx
other::---
default:user::rwx
default:group:rwx
default:group:www-data:r-x
default:group:project1:rwx
default:mask::rwx
default:other::---

Tevens moet ik zorgen dat (binnen en buiten de webroot) mappen schrijfbaar zijn voor Apache, wat ik liever doe met chown dan een directory op 777 zetten. Wat is voor deze werkwijze een goede aanpak?

Je realiseert je dat webserver-writable directories binnen de webroot een security hole zijn he?

[mithras]

deadinspace schreef op zaterdag 02 april 2011 @ 14:17:
[...]

Dat is een situatie waar de standaard Unix permissies niet goed in voorzien. Er zijn verschillende manieren waarop je daar een beetje omheen kunt werken (zie bv dit topic), maar ik denk dat je het beste af bent met ACLs. Het zal even wat moeite kosten om ze door te krijgen, maar daar kun je wel een degelijke oplossing mee maken.

Mijn ervaring met ACLs is ongeveer 0, maar ik vermoed dat iets als dit voor een webroot een aardige stap in de goede richting zou moeten zijn:

# file: /srv/www/project1
# owner: root
# group: root
user::rwx
group:rwx
group:www-data:r-x
group:project1:rwx
mask::rwx
other::---
default:user::rwx
default:group:rwx
default:group:www-data:r-x
default:group:project1:rwx
default:mask::rwx
default:other::---

Dank! Ik ga eens kijken of dit inderdaad de problemen kan oplossen die we met ons beheer hebben. Hopelijk gaat het lukken.

Dat bepaalde topic had ik ook gezocht, omdat ik het eerder al had gezien. Helaas toen niet gevonden op basis van mijn zoekwoorden

[...]

Je realiseert je dat webserver-writable directories binnen de webroot een security hole zijn he?

Ik heb assets (bestanden die users in een cms kunnen uploaden) die worden weggeschreven door www-data. De folders zijn 755, chown www-data:www-data. Wat kan er dan misgaan?

[Kees]

mithras schreef op zaterdag 02 april 2011 @ 14:27:
[...]
Dank! Ik ga eens kijken of dit inderdaad de problemen kan oplossen die we met ons beheer hebben. Hopelijk gaat het lukken.

Dat bepaalde topic had ik ook gezocht, omdat ik het eerder al had gezien. Helaas toen niet gevonden op basis van mijn zoekwoorden

[...]
Ik heb assets (bestanden die users in een cms kunnen uploaden) die worden weggeschreven door www-data. De folders zijn 755, chown www-data:www-data. Wat kan er dan misgaan?

Als het in de webroot is, en apache kan er 'gewoon' weer bij, dan is er een zeker risico aan verbonden. Er hoeft maar een gek een php scriptje te uploaden, en als hij er dan direct bijkan (door bv naar site/upload/scriptje.php te gaan), en het script wordt uitgevoerd, dan is er een probleem.

Uiteraard kun je dingen doen als php uitzetten in die dir, strenge controle op de data die geupload wordt, extensies vervangen etc, maar je zal iets met security moeten doen, gewoon 'upload -> upload dir' kan een security risk zijn als je er niet aan gedacht hebt.

Nog even afgezien van eventuele securityholes in jouw, of de server software, die misbruikt kunnen worden om een file ergens neer te zetten en uit te voeren.

[Keeper of the Keys]

Met ACLs kun je ook een standaard ACL afdwingen/voor instellen per map zodat ook nieuwe bestanden die worden aangemaakt automatisch de juiste rechten hebben.

[mithras]

Kees schreef op zaterdag 02 april 2011 @ 14:34:
[...]

Dus met de conclusie: als je voor deze directories een php flag "engine off" plaatst, is er niet aan de hand?

offtopic:
Hoe moet je anders bestanden aan de buitenwereld openstellen?

Keeper of the Keys schreef op zaterdag 02 april 2011 @ 20:12:
Met ACLs kun je ook een standaard ACL afdwingen/voor instellen per map zodat ook nieuwe bestanden die worden aangemaakt automatisch de juiste rechten hebben.

Ik zie alleen een benchmark waar ik wel van schrik. Uiteraard heeft het impact op prestaties, maar dit is best heftig:

	Without ACL	With ACL
Ext2	9	1743
Ext3	10	3804

Getallen zijn microseconds voor access van bestanden voor de eerste keer. Daarna is het gecached. Maar wat gebeurt er als je het bestand update naar een nieuwe versie? Is dit uiteindelijk wel bruikbaar op een productie-omgeving? Of is gewoon het gebruik van een gezamenlijk account met gezamenlijk password toch een beter compromis?

[CAPSLOCK2000]

mithras schreef op zaterdag 02 april 2011 @ 21:12:
Ik zie alleen een benchmark waar ik wel van schrik. Uiteraard heeft het impact op prestaties, maar dit is best heftig:


[...]
Getallen zijn microseconds voor access van bestanden voor de eerste keer. Daarna is het gecached. Maar wat gebeurt er als je het bestand update naar een nieuwe versie?

Als het net is bijgewerkt, dan staat het ook in je cache.

Is dit uiteindelijk wel bruikbaar op een productie-omgeving? Of is gewoon het gebruik van een gezamenlijk account met gezamenlijk password toch een beter compromis?

Kijk eens naar suexec, daarmee kun je apache als een andere gebruiker laten draaien.

[Keeper of the Keys]

Ik heb acls gebruikt op een productie server, maar die was relatief dedicated (1 of een paar projecten, het doel van de acls was ervoor te zorgen dat de verschillende devs met hun eigen accounts de source konden bewerken en apache er ook bij zou kunnen etc.), die server houd het nog steeds goed uit voor zover ik weet.

Ook moet je je goed realiseren dat de benchmark die je citeerde ondertussen bijna 8 jaar oud is.

Overigens wat ik me herinner van een wordpress install op een machine met ACL was dat wordpress niet keek naar de ACL en dus niet bewust was van het feit dat het wel kon schrijven ondanks dat het bestand niet bij de groep www-data hoorde.
Maar dat zou best ondertussen kunnen zijn veranderd.

Andere alternatieven voor suexec zijn apache-mpm-itk en fast-cgi.