Was sind perfekte Unix-Berechtigungen für übliche Webprojektverzeichnisse?

Was sind die perfekten minimalen Berechtigungen im Oktalformat für das Folgende in einer Webanwendung geschrieben?

1. Ein Verzeichnis, in das der Benutzer statische Dateien (images / swf / js-Dateien) hochgeladen hat, befindet sich
2. Ein Verzeichnis, in das der Administrator statische Dateien (images / swf / js-Dateien) hochgeladen hat, befindet sich
3. Ein Verzeichnis, in dem sich die in der Anwendung verwendeten Bibliotheken befinden
4. Ein Verzeichnis, in dem sich ausführbare / durchsuchbare serverseitige Skripts befinden
5. Ein Verzeichnis, in dem die bereits vorhandenen Dateien (txt oder xml) serverseitig per Code bearbeitet werden

Hier sind meine Vorschläge und Begründungen

1. 555 kann jeder lesen und schreiben, niemand kann ausführen
2. 544, der Besitzer allein kann schreiben, jeder andere kann nur lesen, niemand kann ausführen
3. 000, niemand muss lesen, schreiben oder ausführen, wird nur vom Webserver verwendet?
4. 661 kann der Besitzer lesen, schreiben, jeder andere kann nur ausführen
5. 600, Besitzer kann lesen, schreiben (kann nicht benötigt werden), sonst kann niemand etwas tun

Jetzt interessieren mich zwei Dinge:

1. Gibt es etwas, das häufig in webbasierten Anwendungen verwendet wird und das ich in der ersten Liste verpasst habe?
2. Gibt es etwas, mit dem Sie in der zweiten Liste nicht einverstanden sind, was ist Ihre Alternative und warum ist es besser?

Angenommen, eine 'Webanwendung' läuft auf einem Server (wie Apache, Nginx usw.) und ist in einer dynamischen Skriptsprache (wie PHP, Ruby usw.) geschrieben. Sie haben ein Missverständnis darüber, wer der 'Benutzer' ist.

Der Benutzer ist nicht die Person, die bei Ihrer Anwendung angemeldet ist. Dies und ihre Rolle in der Anwendung (Administrator usw.) sind für das Szenario völlig irrelevant. Der Benutzer ist der Linux-Systembenutzer, unter dem der Prozess ausgeführt wird. Der Code Ihrer Website wird nur als ein Benutzer ausgeführt - es kann der Benutzer Ihres Webservers sein (was nicht wirklich gut ist), oder es kann ein Benutzer sein, der für Ihre Website spezifisch ist (was viel besser ist).

Unter Linux gehören Benutzer zu Gruppen - wir können einen Benutzer zu einer anderen Gruppe hinzufügen und dieser Gruppe Berechtigungen zuweisen.

Bei einem guten Setup wird Ihr Server als ein Benutzer ausgeführt (nennen wir diesen Benutzer "Webserver") und Ihre dynamische Skriptsprache (z. B. über FastCGI) als ein eigener Benutzer (ein Benutzer pro Site - nennen wir unseren ersten Benutzer "Site1"). .

Um Ihre Dateien bereitzustellen, muss der Webserver darauf zugreifen können, und die Skriptsprache muss darauf zugreifen können. Das bedeutet: 'site1' und 'webserver' müssen in der Lage sein, Ihre Dateien zu lesen. Nur einer von ihnen kann jedoch die Dateien "besitzen". Der Besitzer ist der 'Benutzer' (in Benutzer, Gruppe, andere). Wir brauchen auch unsere Skriptsprache, um in das Verzeichnis schreiben zu können (und die Dateien zu lesen, die es geschrieben hat). Der Benutzer 'site1' benötigt daher Lese- und Schreibrechte. Da wir möchten, dass Gruppen- und andere Berechtigungen so restriktiv wie möglich sind, lautet unser "Eigentümer" "site1", und die entsprechenden Benutzerberechtigungen werden gelesen und geschrieben.

Da wir die Berechtigungen für unseren Webserver nicht als anderen 'Benutzer' festlegen können, werden wir 'Webserver' zur Gruppe 'Site1' hinzufügen (Sie können natürlich eine andere Gruppe mit sowohl 'Site1' als auch 'Webserver' erstellen. Alle Mitglieder dieser Gruppe erhalten die gleichen Berechtigungen. Die laxesten Berechtigungen (des Benutzers, der Gruppe oder eines anderen Satzes) werden auf einen bestimmten Benutzer angewendet, um dessen Berechtigungen zu bestimmen.

Es ist erwähnenswert, dass für ein gutes Setup keine Dateien erforderlich sein sollten, die über Ausführungsberechtigungen für eine dynamische Sprache verfügen. Die Dateien werden nicht direkt ausgeführt, sondern in einen Interpreter eingelesen. Zum Ausführen eines typischen Skripts (eines, das nichts schreibt) sind nur Leseberechtigungen erforderlich.

Die Berechtigung 'Ausführen' für Verzeichnisse hat eine andere Bedeutung - sie ermöglicht das Durchlaufen, ohne den Inhalt lesen zu können. Um eine Datei in einem Verzeichnis lesen zu können, muss ein Benutzer für JEDES darüber liegende Verzeichnis über Ausführungsberechtigungen verfügen.

Für eine Webanwendung muss jede Datei über die Leseberechtigung ihres Besitzers verfügen. Andernfalls ist die Datei ziemlich sinnlos. Unabhängig davon, ob ein Benutzer oder ein Administrator Dateien (über Ihre Webanwendung) hochlädt, benötigt der Eigentümer (dh die dynamische Sprache) Schreibberechtigungen. Bei einem effizienten Setup wird versucht, statische Dateien direkt über den Webserver bereitzustellen, da dynamische Sprachen beim Einlesen großer Dateien und beim Ausgeben des Inhalts in der Regel langsam sind. Der Webserver benötigt daher Lesezugriff auf Ihre statischen Dateien.

Daher können die minimalen Dateiberechtigungen sein:

• Eine Datei in einem Verzeichnis, in das der Benutzer statische Dateien (images / swf / js-Dateien) hochgeladen hat, befindet sich in folgendem Verzeichnis: 640
• Eine Datei in einem Verzeichnis, in das der Administrator statische Dateien (images / swf / js-Dateien) hochgeladen hat, befindet sich in folgendem Verzeichnis: 640
• Eine Datei in einem Verzeichnis, in dem sich die in der Anwendung verwendeten Bibliotheken befinden: 400 (oder 440)
• Eine Datei in einem Verzeichnis, in dem sich ausführbare / durchsuchbare serverseitige Skripts befinden: 400 (oder 440)
• Eine Datei in einem Verzeichnis, in dem die bereits vorhandenen Dateien (txt oder xml) nach Code auf der Serverseite bearbeitet werden: 640 oder 600
  • (hängt davon ab, ob der Webserver diese zeitweise unverändert anzeigt)

Die minimalen Verzeichnisberechtigungen können sein:

• Ein Verzeichnis, in das der Benutzer statische Dateien (images / swf / js-Dateien) hochgeladen hat, befindet sich: 750
• Ein Verzeichnis, in das der Administrator statische Dateien (images / swf / js-Dateien) hochgeladen hat, befindet sich: 750
• Ein Verzeichnis, in dem sich die in der Anwendung verwendeten Bibliotheken befinden: 500 (oder 550) [sollte mindestens 510 sein]
• Ein Verzeichnis, in dem sich ausführbare / durchsuchbare serverseitige Skripts befinden: 500 (oder 550) [sollte mindestens 510 sein]
• Ein Verzeichnis, in dem die bereits vorhandenen Dateien (txt oder xml) serverseitig per Code bearbeitet werden: 750 oder 700
  • (hängt davon ab, ob der Webserver von hier aus Dateien bereitstellt, die zeitweise unverändert sind)

Auch hier gilt: Ihr Webserver muss für jedes Verzeichnis über dem Verzeichnis, auf das er Zugriff hat, über Ausführungsberechtigungen verfügen. Selbst wenn der Webserver keine Dateien aus einem bestimmten Verzeichnis bereitstellt, sollten wir ihm Ausführungsberechtigungen erteilen.

Es ist ziemlich üblich, dem Webserver Lesezugriff auf die meisten Dateien zu gewähren (ändern Sie diese 500 auf 550). Standardmäßige "etwas sichere" Berechtigungen sind 755 für Verzeichnisse und 644 für Dateien - keine Ausführungsberechtigungen, jeder kann lesen und nur der Benutzer kann schreiben - Sie werden feststellen, dass die überwiegende Mehrheit der Dateien auf einem Linux-System über diese Berechtigungen verfügt.

Beachten Sie, dass sich die "anderen" Berechtigungen auf jeden Systembenutzer beziehen, der nicht der Eigentümer oder in der Gruppe ist (dh alle verbleibenden Systembenutzer). Die Einschränkung Ihrer "anderen" Berechtigungen ist gut, da diese Benutzer unbekannt sind - Sie haben ihnen keine explizite Berechtigung erteilt. Die anderen Berechtigungen sind auf einem kompromittierten System oft am einfachsten zu nutzen (z. B. einer der Gründe, warum / tmp ein häufiges Ziel ist).

Im Zusammenhang mit dem oben Gesagten denke ich nicht, dass Ihre letzten beiden Fragen so relevant sind. Setzen Sie Ihre Verzeichnisberechtigungen auf 550 (und Dateiberechtigungen auf 440) und erteilen Sie dem Benutzer Schreibberechtigungen für alle Verzeichnisse, in die Ihre Anwendung schreibt (dh Verzeichnis: 750; Datei: 640).

(Sie benötigen natürlich Schreibrechte, um die Dateien hochzuladen. Wenn Sie dies wünschen, können Sie diese nachträglich entfernen. Wenn jedoch jemand in ein Verzeichnis schreibt, in das nur der Eigentümer schreiben kann, ist Ihr Konto kompromittiert worden. Dies ist eines der Gründe für die Beibehaltung restriktiver Berechtigungen).

Es ist normal, über die Mindestberechtigung zu verfügen, um die Arbeit zu erledigen. Wenn Ihr Webserver und die Benutzer eine gemeinsame Gruppe haben, müssen Sie keinen Zugriff mehr gewähren o. Berechtigungen beziehen sich auch auf Benutzer. Sie scheinen die oktalen Berechtigungen falsch verstanden zu haben.

1. 555 ist r-xr-xr-xnicht rw-rw-rw. Da es sich dann um ein Verzeichnis zum Erstellen / Löschen von Dateien handelt, müssen Sie festgelegt haben x, dass 750 rwxr-x---ein guter Ausgangspunkt wäre. Auf diese Weise kann der Benutzer, dem das Verzeichnis gehört, Dateien hinzufügen / entfernen und jeder in der allgemeinen Gruppe darauf zugreifen.
2. Das Gleiche wie 1. oben.
3. Wenn es sich wirklich um statische Dateien handelt, würde 050 dem Webserver Zugriff gewähren. Das erstmalige Erstellen der Dateien wäre jedoch ein Minimum von 750.
4. Das gleiche wie 3 oben.
5. 070 ist das Minimum, damit der Webserver die Dateien lesen und ändern kann, aber die Dateien müssen erstellt werden, damit 770 wahrscheinlich realistischer ist.

Im Allgemeinen würde man für Verzeichnisse den Modus 0755, 0775 oder 2775 verwenden (das SGID-Bit für Verzeichnisse, für BSD und für Linux, wenn das Dateisystem mit BSD-Semantik gemountet ist, bewirkt, dass die Gruppenzuordnung neuer Dateien mit den Einstellungen des übergeordneten Verzeichnisses übereinstimmt, und nicht mit denen von Standard-GID des Erstellers der Datei). Auf diese Weise können alle Benutzer die betreffenden Verzeichnisse durchsuchen (chdir in und durch) und lesen (den Befehl ls ausführen oder die Systemaufrufe readdir / read ausführen). Mit den Alternativen werden Gruppen- / Schreiboptionen hinzugefügt. Wie bereits erwähnt, kann das SGID-Bit in Verzeichnissen dazu beitragen, dass alle Dateien und Unterverzeichnisse einer geeigneten Gruppe zugeordnet bleiben.

Für Dateien würde man normalerweise 0644 oder möglicherweise 0664 verwenden (weltweit lesbar und entweder gruppenbeschreibbar oder nicht). Offensichtlich muss für CGI-Skripte und Binärdateien das x-Bit hinzugefügt werden. In einigen speziellen Situationen, in denen die Binärdateien sehr gut getestet wurden, können SUID- oder SGID-Bits hinzugefügt werden. Normalerweise ignorieren UNIX und Linux das SUID / SGID-Bit in Skripten und berücksichtigen seine Semantik nur für nativ kompilierte ausführbare Binärdateien. Möglicherweise führen Sie Ihre Site jedoch unter Apache mit einem Modul wie "setuidhack" aus, mit dem der Webserver die SUID / SGID-Bits auch in interpretierten Skripten berücksichtigen kann. (Dies geschieht, indem der HTTP-Dämon stat () jede Datei mit einem eigenen, benutzerdefinierten fork () / execve () -Code anordnet und die korrekte Interpreterzeichenfolge in den execve () -Vektor interpoliert, anstatt nur die ausführbare Datei zu übergeben. '

Dies sind nur die allgemeinsten Richtlinien. Sie sind nicht für alle Situationen "perfekt" und Sie sollten auf jeden Fall die Dokumente für Ihren Webserver und alle Webanwendungen oder Frameworks konsultieren, die Sie installieren und konfigurieren ... und Sie sollten sich wahrscheinlich vorab an einen UNIX-Sicherheitsexperten wenden Setzen Sie alle Ihre Dateien, Codes oder Server dem öffentlichen Internet aus.