Welche Berechtigungen sollten meine Website-Dateien / -Ordner auf einem Linux-Webserver haben?

Dies ist eine kanonische Frage zu Dateiberechtigungen auf einem Linux-Webserver.

Ich habe einen Linux-Webserver mit Apache2, auf dem mehrere Websites gehostet werden. Jede Website hat einen eigenen Ordner in / var / www /.

/var/www/contoso.com/
/var/www/contoso.net/
/var/www/fabrikam.com/

Das Basisverzeichnis / var / www / gehört root: root. Apache läuft als www-data: www-data. Die Fabrikam-Website wird von zwei Entwicklern, Alice und Bob, gepflegt. Beide Contoso-Websites werden von einem Entwickler, Eve, verwaltet. Auf allen Websites können Benutzer Bilder hochladen. Wenn eine Website kompromittiert wird, sollte die Auswirkung so gering wie möglich sein.

Ich möchte wissen, wie ich Berechtigungen am besten einrichte, damit Apache den Inhalt bereitstellen kann, die Website vor Angriffen geschützt ist und die Entwickler weiterhin Änderungen vornehmen können. Eine der Websites ist folgendermaßen aufgebaut:

/var/www/fabrikam.com
    /cache
    /modules
    /styles
    /uploads
    /index.php

Wie sollen die Berechtigungen für diese Verzeichnisse und Dateien festgelegt werden? Ich habe irgendwo gelesen, dass Sie niemals 777-Berechtigungen für eine Website verwenden sollten, aber ich verstehe nicht, welche Probleme dies verursachen könnte. In Stoßzeiten speichert die Website einige Seiten automatisch im Cache und speichert die Ergebnisse im Cache-Ordner. Alle von Website-Besuchern eingereichten Inhalte werden im Upload-Ordner gespeichert.

Wenn Sie entscheiden, welche Berechtigungen verwendet werden sollen, müssen Sie genau wissen, wer Ihre Benutzer sind und was sie benötigen. Ein Webserver interagiert mit zwei Benutzertypen.

Authentifizierte Benutzer haben ein Benutzerkonto auf dem Server und können mit bestimmten Berechtigungen ausgestattet werden. Dies umfasst normalerweise Systemadministratoren, Entwickler und Dienstkonten. Sie nehmen normalerweise Änderungen am System mit SSH oder SFTP vor.

Anonyme Benutzer sind die Besucher Ihrer Website. Sie haben zwar keine Berechtigung, direkt auf Dateien zuzugreifen, können jedoch eine Webseite anfordern und der Webserver handelt in ihrem Namen. Sie können den Zugriff anonymer Benutzer einschränken, indem Sie sorgfältig festlegen, über welche Berechtigungen der Webserverprozess verfügt. Auf vielen Linux-Distributionen wird Apache als www-dataBenutzer ausgeführt, kann jedoch unterschiedlich sein. Verwenden Sie ps aux | grep httpdoder, um ps aux | grep apachezu sehen, welchen Benutzer Apache auf Ihrem System verwendet.

Hinweise zu Linux-Berechtigungen

Linux und andere POSIX-kompatible Systeme verwenden herkömmliche Unix-Berechtigungen. Es gibt auf Wikipedia einen ausgezeichneten Artikel über Dateisystemberechtigungen, so dass ich hier nicht alles wiederholen werde. Aber es gibt ein paar Dinge, die Sie beachten sollten.

Das Ausführungsbit
Interpreted Scripts (zB Ruby, PHP) funktionieren ohne die Ausführungsberechtigung einwandfrei. Nur Binärdateien und Shell-Skripte benötigen das Ausführungsbit. Um ein Verzeichnis zu durchlaufen (einzugeben), müssen Sie über die Ausführungsberechtigung für dieses Verzeichnis verfügen. Der Webserver benötigt diese Berechtigung, um ein Verzeichnis aufzulisten oder darin enthaltene Dateien bereitzustellen.

Standardberechtigungen für neue Dateien
Wenn eine Datei erstellt wird, erbt sie normalerweise die Gruppen-ID des Erstellers. Manchmal möchten Sie jedoch, dass neue Dateien die Gruppen-ID des Ordners erben, in dem sie erstellt wurden, sodass Sie das SGID-Bit für den übergeordneten Ordner aktivieren.

Die Standardberechtigungswerte hängen von Ihrer umask ab. Die umask subtrahiert Berechtigungen von neu erstellten Dateien, sodass der gemeinsame Wert 022 dazu führt, dass Dateien mit 755 erstellt werden. Bei der Zusammenarbeit mit einer Gruppe ist es hilfreich, die umask in 002 zu ändern, damit die von Ihnen erstellten Dateien von Gruppenmitgliedern geändert werden können. Und wenn Sie die Berechtigungen für hochgeladene Dateien anpassen möchten, müssen Sie entweder die umask für Apache ändern oder chmod ausführen, nachdem die Datei hochgeladen wurde.

Das Problem mit 777

Wenn Sie chmod 777Ihre Website, haben Sie überhaupt keine Sicherheit. Jeder Benutzer im System kann eine beliebige Datei auf Ihrer Website ändern oder löschen. Denken Sie jedoch ernsthaft daran, dass der Webserver im Namen der Besucher Ihrer Website handelt und dass der Webserver nun die gleichen Dateien ändern kann, die er ausführt. Wenn Ihre Website Sicherheitslücken in Bezug auf die Programmierung aufweist, können diese ausgenutzt werden, um Ihre Website zu entstellen, Phishing-Angriffe einzufügen oder Informationen von Ihrem Server zu stehlen, ohne dass Sie dies jemals merken.

Wenn Ihr Server außerdem an einem bekannten Port ausgeführt wird (der verhindern soll, dass Benutzer ohne Rootberechtigung weltweit zugängliche Abhördienste starten), muss Ihr Server von root gestartet werden (obwohl jeder vernünftige Server sofort ausfällt) auf einen weniger privilegierten Account, sobald der Port gebunden ist). Mit anderen Worten, wenn Sie einen Webserver ausführen, auf dem die ausführbare Hauptdatei Teil der Versionskontrolle ist (z. B. eine CGI-App), und dessen Berechtigungen (oder auch die Berechtigungen des enthaltenen Verzeichnisses) belassen, da der Benutzer sie umbenennen könnte Die ausführbare Datei bei 777 ermöglicht es jedem Benutzer, eine beliebige ausführbare Datei als root auszuführen .

Definieren Sie die Anforderungen

• Entwickler benötigen Lese- / Schreibzugriff auf Dateien, um die Website aktualisieren zu können
• Entwickler müssen Verzeichnisse lesen / schreiben / ausführen, damit sie sich darin bewegen können
• Apache benötigt Lesezugriff auf Dateien und interpretierte Skripte
• Apache benötigt Lese- / Ausführungszugriff auf serveable Verzeichnisse
• Apache benötigt Lese- / Schreib- / Ausführungszugriff auf Verzeichnisse für hochgeladene Inhalte

Von einem einzelnen Benutzer verwaltet

Wenn nur ein Benutzer für die Wartung der Site verantwortlich ist, legen Sie ihn als Benutzerbesitzer im Website-Verzeichnis fest und erteilen Sie dem Benutzer die vollständigen Rechte für RWX. Apache benötigt weiterhin Zugriff, damit es die Dateien bedienen kann. Legen Sie also www-data als Gruppeneigentümer fest und erteilen Sie der Gruppe Empfangsberechtigungen.

In Ihrem Fall ist Eve, deren Benutzername möglicherweise evelautet, der einzige Benutzer, der Folgendes verwaltet contoso.com:

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Wenn Sie Ordner haben, die von Apache beschreibbar sein müssen, können Sie einfach die Berechtigungswerte für den Gruppenbesitzer so ändern, dass www-data Schreibzugriff hat.

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

Der Vorteil dieser Konfiguration besteht darin, dass es für andere Benutzer im System schwieriger (aber nicht unmöglich *) wird, nachzuschauen, da nur die Benutzer und Gruppenbesitzer Ihr Website-Verzeichnis durchsuchen können. Dies ist nützlich, wenn Ihre Konfigurationsdateien geheime Daten enthalten. Sei vorsichtig mit deiner umask! Wenn Sie hier eine neue Datei erstellen, werden die Berechtigungswerte wahrscheinlich standardmäßig auf 755 gesetzt. Sie können ausführen, umask 027sodass neue Dateien standardmäßig auf 640 ( rw- r-- ---) gesetzt werden.

Wird von einer Benutzergruppe verwaltet

Wenn mehr als ein Benutzer für die Wartung der Site verantwortlich ist, müssen Sie eine Gruppe erstellen, die zum Zuweisen von Berechtigungen verwendet werden kann. Es hat sich bewährt, für jede Website eine eigene Gruppe zu erstellen und die Gruppe nach dieser Website zu benennen.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

Im vorherigen Beispiel haben wir den Gruppeneigentümer verwendet, um Apache Berechtigungen zu erteilen, aber jetzt wird dies für die Entwicklergruppe verwendet. Da der Eigentümer des Benutzers für uns nicht mehr nützlich ist, können Sie auf einfache Weise sicherstellen, dass keine Berechtigungen verloren gehen, indem Sie ihn auf root setzen. Apache benötigt weiterhin Zugriff, sodass wir dem Rest der Welt Lesezugriff gewähren.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Wenn Sie Ordner haben, die von Apache beschreibbar sein müssen, können Sie Apache entweder zum Benutzer- oder zum Gruppenbesitzer machen. In jedem Fall hat es alle erforderlichen Zugriffsrechte. Persönlich bevorzuge ich es, den Benutzer zum Eigentümer zu machen, damit die Entwickler weiterhin den Inhalt der Upload-Ordner durchsuchen und ändern können.

chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Obwohl dies ein gängiger Ansatz ist, gibt es einen Nachteil. Da jeder andere Benutzer auf dem System die gleichen Berechtigungen für Ihre Website hat wie Apache, können andere Benutzer problemlos auf Ihrer Website surfen und Dateien lesen, die möglicherweise geheime Daten enthalten, z. B. Ihre Konfigurationsdateien.

Sie können Ihren Kuchen haben und ihn auch essen

Dies kann weiter verbessert werden. Es ist völlig legal, dass der Eigentümer weniger Rechte als die Gruppe hat. Anstatt den Eigentümer des Benutzers durch Zuweisen zu root zu verschwenden, können wir Apache zum Eigentümer des Benutzers für die Verzeichnisse und Dateien auf Ihrer Website machen. Dies ist eine Umkehrung des Single-Maintainer-Szenarios, funktioniert aber genauso gut.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Wenn Sie Ordner haben, die von Apache beschreibbar sein müssen, können Sie einfach die Berechtigungswerte für den Benutzerbesitzer so ändern, dass www-data Schreibzugriff hat.

chmod u+w uploads
ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Eine Sache, die Sie bei dieser Lösung beachten sollten, ist, dass der Benutzer, der Eigentümer neuer Dateien ist, dem Ersteller entspricht, anstatt auf www-data gesetzt zu werden. Alle neuen Dateien, die Sie erstellen, können von Apache erst gelesen werden, wenn Sie sie erkannt haben.

* Trennung der Apache-Privilegien

Ich habe bereits erwähnt, dass es anderen Nutzern tatsächlich möglich ist, sich auf Ihrer Website umzuschauen, unabhängig davon, welche Art von Berechtigungen Sie verwenden. Standardmäßig werden alle Apache-Prozesse als derselbe WWW-Datenbenutzer ausgeführt, sodass jeder Apache-Prozess Dateien von allen anderen auf demselben Server konfigurierten Websites lesen und manchmal sogar Änderungen vornehmen kann. Jeder Benutzer, der Apache zum Ausführen eines Skripts auffordert, kann denselben Zugriff wie Apache selbst erhalten.

Um dieses Problem zu bekämpfen, gibt es in Apache verschiedene Ansätze zur Trennung von Berechtigungen . Jeder Ansatz weist jedoch verschiedene Leistungs- und Sicherheitsnachteile auf. Meiner Meinung nach sollte jede Site mit höheren Sicherheitsanforderungen auf einem dedizierten Server ausgeführt werden, anstatt VirtualHosts auf einem gemeinsam genutzten Server zu verwenden.

Weitere Überlegungen

Ich habe es vorher nicht erwähnt, aber es ist normalerweise eine schlechte Praxis, wenn Entwickler die Website direkt bearbeiten. Bei größeren Websites ist es viel besser, ein Release-System zu haben, das den Webserver über die Inhalte eines Versionskontrollsystems aktualisiert. Der Single-Maintainer-Ansatz ist wahrscheinlich ideal, aber statt einer Person haben Sie eine automatisierte Software.

Wenn Ihre Website Uploads zulässt, die nicht ausgeliefert werden müssen, sollten diese Uploads außerhalb des Webstamms gespeichert werden. Andernfalls werden möglicherweise Dateien heruntergeladen, die geheim sein sollten. Wenn Sie beispielsweise zulassen, dass Schüler Aufgaben senden, sollten sie in einem Verzeichnis gespeichert werden, das nicht von Apache bereitgestellt wird. Dies ist auch ein guter Ansatz für Konfigurationsdateien, die Geheimnisse enthalten.

Bei einer Website mit komplexeren Anforderungen sollten Sie sich mit der Verwendung von Zugriffssteuerungslisten befassen . Diese ermöglichen eine weitaus differenziertere Steuerung von Berechtigungen.

Wenn Ihre Website komplexe Anforderungen hat, möchten Sie möglicherweise ein Skript schreiben, mit dem alle Berechtigungen eingerichtet werden. Testen Sie es gründlich und bewahren Sie es gut auf. Es könnte sein Gewicht in Gold wert sein, wenn Sie jemals feststellen, dass Sie Ihre Website aus irgendeinem Grund neu erstellen müssen.

Ich frage mich, warum so viele Leute den "anderen" (o) Teil der Linux-Rechte verwenden (oder empfehlen), um zu steuern, was Apache (und / oder PHP) kann. Indem Sie diesen rechten Teil auf einen anderen Wert als "0" setzen, können Sie der ganzen Welt erlauben, etwas in der Datei / im Verzeichnis zu tun.

Mein Ansatz ist folgender:

• Ich erstelle zwei getrennte Benutzer. Einer für den SSH / SFTP-Zugriff (falls erforderlich), der alle Dateien enthält, und einer für den PHP FastCGI-Benutzer (den Benutzer, unter dem die Website ausgeführt wird). Nennen wir diese Benutzer bzw. bob und bob-www .
• bob hat die vollen Rechte ( rwx für Ordner, rw- on-Dateien), damit er die gesamte Website lesen und bearbeiten kann.
• Der PHP-FastCGI-Prozess benötigt RX- Rechte für Ordner und R--- Rechte für Dateien, mit Ausnahme von sehr spezifischen Ordnern wie cache/oder uploads/, für die ebenfalls die Berechtigung "Schreiben" erforderlich ist. Um PHP FastCGI diese Möglichkeit zu geben, wird es als Bob-WWW ausgeführt und Bob-WWW wird der automatisch erstellten Bob- Gruppe hinzugefügt .
• Wir stellen jetzt sicher, dass der Eigentümer und die Gruppe aller Verzeichnisse und Dateien Bob Bob sind .
• Es fehlt etwas: Sogar wir verwenden FastCGI, aber Apache benötigt weiterhin Lesezugriff für statische Inhalte oder .htaccess-Dateien, die es zu lesen versucht, wenn AllowOverrideetwas anderes als festgelegt ist None. Um die Verwendung des o- Teils der Rechte zu vermeiden , füge ich den Benutzer www-data der bob- Gruppe hinzu.

Jetzt:

• Um zu kontrollieren, was der Entwickler tun kann, können wir mit dem u- Teil der Rechte spielen (dies ist jedoch der Hinweis unten).
• Um zu kontrollieren, was Apache und PHP können, können wir mit dem g- Teil der Rechte spielen.
• Der Teil o ist immer auf 0 gesetzt, damit niemand auf dem Server die Website lesen oder bearbeiten kann.
• Es gibt kein Problem, wenn der Bob- Benutzer neue Dateien erstellt, da diese automatisch zu seiner Hauptgruppe ( Bob ) gehören.

Dies ist eine Zusammenfassung, aber in dieser Situation darf Bob SSH. Wenn es keinen Benutzer geben sollte, der die Website ändern darf (z. B. der Kunde ändert die Website nur über ein CMS-Administrationsfenster und verfügt nicht über Linux-Kenntnisse), erstellen Sie trotzdem zwei Benutzer, geben Sie aber auch /bin/falseals Shell für bob und an Deaktivieren Sie die Anmeldung.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Hinweis: Die Leute neigen dazu zu vergessen, dass das Einschränken der u- Rechte (der Rechteinhaber) die meiste Zeit nutzlos und unsicher ist, da der Eigentümer einer Datei den chmodBefehl ausführen kann , selbst die Rechte sind 000.

Sagen Sie mir, ob mein Ansatz einige Sicherheitsprobleme aufweist, da ich nicht zu 100% sicher bin, aber es ist das, was ich verwende.

Ich denke, diese Konfiguration hat ein Problem: Wenn PHP / Apache eine neue Datei erstellt (zB Upload), gehört sie zu bob-www: bob und bob kann sie nur lesen. Vielleicht kann setuid im Verzeichnis das Problem lösen.

Angesichts des Google-Rangs für die oben genannte ausgezeichnete Antwort sollte meines Erachtens eines beachtet werden, und ich kann nach der Antwort scheinbar keine Notiz hinterlassen.

Wenn Sie mit dem Beispiel fortfahren und www-data als Eigentümer und dev-fabrikam als Gruppe mit 570 Berechtigungen für das Verzeichnis (oder die Datei) verwenden möchten, ist es wichtig zu beachten, dass Linux ignoriert wird setuid , sodass alle neuen Dateien Eigentum von sind Benutzer, der sie erstellt hat. Dies bedeutet, dass Sie nach dem Erstellen neuer Verzeichnisse und Dateien Folgendes verwenden müssen:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

In Ubuntu 12.04 für Rackspace OpenStack hatte ich ein seltsames Problem, bei dem ich die Berechtigungen 570 erst nach einem Neustart des Servers erhalten konnte, wodurch das Problem auf magische Weise behoben wurde. Verlor in zunehmendem Maße Haare wegen dieser scheinbar einfachen Angelegenheit ...

Ich gehe mit dieser Konfiguration:

1. Alle Verzeichnisse mit Ausnahme des Uploads eines Satzes an Eigentümer rootund Gruppe root, Berechtigungen an 0755.
2. Alle Dateien auf Eigentümer rootund Gruppe festgelegt root, Berechtigungen auf 0644.
3. Lädt das Verzeichnis hoch, das auf Eigentümer root, Gruppe www-dataund Berechtigungen festgelegt ist 1770. Mit dem Sticky-Bit kann der Gruppenbesitzer das darin enthaltene Verzeichnis und die darin enthaltenen Dateien nicht entfernen oder umbenennen.
4. Im Upload- Ordner befindet sich ein neues Verzeichnis mit dem www-dataBenutzer und der Gruppe des Besitzers sowie den 0700Berechtigungen für jeden www-dataBenutzer, der Dateien hochlädt .
5. Apache-Konfiguration:

Verweigern AllowOverrideund Indexim Upload-Verzeichnis, damit Apache keine .htaccessDateien liest und Apache-Benutzer den Inhalt des Upload-Ordners nicht indizieren können:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.iniKonfiguration:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Mit dieser Konfiguration kann der www-dataBenutzer keine anderen Verzeichnisse als siteDir/ /tmpund aufrufen /usr/share/phpmyadmin. Sie können auch die maximale Dateigröße, die maximale Postgröße und die maximale Anzahl der Dateien festlegen, die in derselben Anfrage hochgeladen werden sollen.

Wenn Sie einen FTP-Benutzer namens "leo" haben, der Dateien in das example.com-Webverzeichnis hochladen muss, und Sie möchten, dass Ihr Apache-Benutzer Uploa-Dateien / Sessions / Cache-Dateien im Cache-Verzeichnis erstellen kann, gehen Sie wie folgt vor:

Dieser Befehl weist "leo" als Eigentümer und "group" als Apache zu "example.com" zu. Der Benutzer "apache" ist Teil der Gruppe "apache", sodass er die Berechtigungen der Gruppe "apache" erbt

chown -R leo: apache example.com

Ein weiterer Befehl, der die Erlaubnis versichert und auch Sicherheitsbedenken erfüllt.

chmod -R 2774 example.com

Hier steht die erste Nummer 2 für das Verzeichnis und stellt sicher, dass jede neu erstellte Datei in den gleichen Gruppen- und Besitzerberechtigungen bleibt. 77 ist für Eigentümer und Gruppen bedeutet, dass sie vollen Zugriff haben. 4 bedeutet für andere, dass sie nur durchlesen können.

Folgendes ist hilfreich, um die Berechtigungsnummern zu verstehen

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

IMO muss man berücksichtigen:

• Vertrauen Sie einem Prozess, der Ihre Dateien liest? z.B. PHP?

Nehmen wir an, Sie haben einen Server, der verschiedene Daten unter Benutzer "testet".

Der 'Test'-Benutzer hat dort:

• seine Daten in $HOMEDIR
• seine Mail in $MAIL
• seine Daten für das Web in /var/www/test

Nun überlegen wir uns:

• Eine Web-App läuft unter testUser (PHP-FPM) - sie kann jede seiner Dateien löschen!
• Eine Web-App wird unter einer testGruppe ausgeführt (PHP-FPM). Sie kann alle Dateien löschen, in denen das Verzeichnis 'w' für die Gruppe enthält, und alle Dateien ändern, in denen 'r' für die Gruppe enthalten ist. und es könnte sie noch lesen - Ihre SSH-Schlüssel zum Beispiel!

Nehmen wir an, PHP ist fehlerhaft und es ist, vertrauen Sie seiner open_basedir? Machst du chrootdeinen PHP-Prozess? Was machst du nicht, willst du, dass es durch das gesamte Dateisystem kriecht?

Ihr Web-App-Prozess, z. PHP-FPM sollte dann:

• auf einen bestimmten Pfad beschränkt sein über chroot
• sollte nicht unter dem primären Benutzer oder der primären Gruppenberechtigung des Datenbesitzers ausgeführt werden

So können Sie:

• Testbenutzer ist: test:test
• Testbenutzer ist in einer sekundären Gruppe, z. test-www
• Eine Web-App (PHP-FPM) läuft unter test-www:test-www
• Testbenutzer, wenn er möchte, dass die Web-App seine Dateien lesen kann, tun Folgendes: chmod u=rwX,g=rX,o= /var/www/test/public
• Testbenutzer, wenn er möchte, dass die Web-App in seinen Web-Datenpfad schreiben kann: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (Die App erstellt also neue Dateien als: test-www:test-www- Sie hat eine Test-WWW-Gruppe, weil setgid im Verzeichnis ist!)

Wenn also der Web-App-Prozess gefälscht wäre, würde er nur bestimmte Dateien lesen, bei denen die Gruppe gelesen wurde, und er wäre in der Lage, nur in uploaddir zu schreiben . Ich würde dringend empfehlen, dieses uploadVerzeichnis auf einem Dateisystem mit noexec,nodev,nosuid mountOptionen zu haben und ständig nach neuen bizzare-Dateien in diesem Verzeichnis zu suchen sowie alle neuen Prozesse unter test-wwwuid zu überwachen.

Unter Linux könnte man ACL verwenden, um die Berechtigungen besser abzustimmen. Wenn mehr als eine Person Webdaten hochladen soll, ist es besser, das Benutzerkonto von dem Konto zu trennen, das zum Hochladen von Webdatendateien verwendet wird, d. H. um ein neues Konto zu erstellen, zB. test-upload, und Testbenutzer würden ssh-Schlüssel verwalten, um einzuschränken, welcher Mensch dort ssh / sftp könnte. sshd_configkennt ExposeAuthInfoOptionen und kann so konfiguriert werden, dass protokolliert wird, welcher SSH-Schlüssel zum Hochladen der Daten verwendet wurde.

Ich bezweifle wirklich, dass die meisten Webhosting-Dienste sich um die Trennung von Privilegien kümmern. Wenn sie "sicher" schreiben, ohne Informationen darüber, was Sie erhalten, würde ich sagen, dass sie lügen.