Userechte: Dateien ins Dateisystem speichern...

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 2. Juli 2007, 17:21

Wir besprechen gerade ein wenig, warum PyLucid nicht mehr Sachen im Dateisystem organisiert bzw. beläßt... Ich kommt dann immer mit der selben Begründung an:
Normalerweise läuft der Web-Server mit dem User "www-data" oder "nobody". Beide User dürfen erstmal keine Dateien auf Platte schreiben!
Eine Reihe an work-a-rounds habe ich hier aufgeschrieben: http://pylucid.org/phpBB2/viewtopic.php?t=144

Ein richtig eingerichtete suexec Lösung ist die beste, das ist klar... Aber was ist mit dem armen Menschen die nur einen schnöde CGI-only WebHoster haben?
Diejenigen müssten einen Ordner mit schreibrechten für alle einrichten und fertig...

Und jetzt die große Frage: Mal abgesehen vom mulmigen Gefühlt im Bauch, welches Sicherheitsrisiko geht man in der Praxis mit "Schreibrechte für alle" wirklich ein?

Weiß ja jemand was drüber???

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Quash
User
Beiträge: 9
Registriert: Donnerstag 5. Juli 2007, 01:53

Donnerstag 5. Juli 2007, 02:42

Hi, ein höheres Sicherheitsrisiko als das kannst du gar nicht haben.
Lass es lieber.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 5. Juli 2007, 08:23

Kannst du das auch begründen?

Ich hatte mal einen Test bei 1blu gemacht.
Ein Freund von mir und ich hatten normalen Shared-Webspace auf dem gleichen Server. Wir haben ein Verzeichnis, mit Schreibrechte für alle, angelegt. Dann haben wir versucht auf das jeweilige andere Verzeichnis rein zu kommen (wir haben den absoluten Pfad ausgetauscht), aber es funktionierte nicht.

Normalerweise sollte es aber gehen, zumindest beim Standard Linux System.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Donnerstag 5. Juli 2007, 08:34

Schreibrechte für alle auf einen Ordner ist nicht wirklich ein Problem, wieso auch? Das Problem ist mehr wenn du auf sämtliche Dateien Schreibrechte gibst und dich in einer Sharedhosting Umgebung befindest. Dann kann jeder in deinen Daten rumpfuschen. Grundsätzlich ist es jedoch möglich *cgi Prozesse mit anderen Rechten laufen zu lassen.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 5. Juli 2007, 08:52

Ich hätte erwähnen müssen, das dieses Verzeichnis nur für statische Dateien gedacht ist. Bilder, html, css, js und sowas... Skripte sollten da nicht rein, bzw. sollen nicht von da gestartet werden.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Quash
User
Beiträge: 9
Registriert: Donnerstag 5. Juli 2007, 01:53

Donnerstag 5. Juli 2007, 19:40

Kein Problem? Sorry, gehts noch? :D
Jeder Benutzer kann deine Dateien löschen, aber nein, es ist kein Problem.
In einer chroot-Umgebung stellt sich die Frage nicht, da man sowieso nur auf sein eigenes $HOME zugreifen kann.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Donnerstag 5. Juli 2007, 21:50

Quash hat geschrieben:Kein Problem? Sorry, gehts noch? :D
Jeder Benutzer kann deine Dateien löschen, aber nein, es ist kein Problem.
In einer chroot-Umgebung stellt sich die Frage nicht, da man sowieso nur auf sein eigenes $HOME zugreifen kann.
Und aus genau diesem Grund wurde das Sticky Bit erfunden ;)

Beim Chroot hast du das Problem dass du für jeden User eine ganze chroot Umgebung brauchst. Eine Alternative ist cgi/fcgi Scripts nicht mit Webserver sondern Benuter Rechten laufen zu lassen. Im Apache gibt es für CGI Scripte suExec hat aber auch so seine Nachteile.
Benutzeravatar
Quash
User
Beiträge: 9
Registriert: Donnerstag 5. Juli 2007, 01:53

Sonntag 8. Juli 2007, 14:49

Ok, ich baue ein chroot um es dann wieder zu umschiffen. Grandiose Idee und vor allem sicher. :-)

"Ich lösche es mal lieber nicht. Wer weiß, vielleicht tuts was."
Mephisto
User
Beiträge: 28
Registriert: Mittwoch 17. Januar 2007, 15:52

Sonntag 8. Juli 2007, 15:22

Quash hat geschrieben:Ok, ich baue ein chroot um es dann wieder zu umschiffen. Grandiose Idee und vor allem sicher. :-)

"Ich lösche es mal lieber nicht. Wer weiß, vielleicht tuts was."
Kommen da noch Argumente für _einen_ deiner Beiträge oder hörst du dich nur gerne selber reden?
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Sonntag 8. Juli 2007, 16:29

Mephisto hat geschrieben:Kommen da noch Argumente für _einen_ deiner Beiträge oder hörst du dich nur gerne selber reden?
Danke! :twisted:
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 9. Juli 2007, 07:42

Im aktuellen Linux Magazin wird suexec vorgestellt. Um genau die "world-writeable" Geschichte zu umgehen. Als Grund, weswegen man das vermeiden sollte, wird nur angegeben, weil andere User die Dateien überschreiben könnte.

Im Grunde ist ein "world-writeable" Ordner eine "*-Injektion" Lücke, für alle User auf der selben Maschine.
Egal was ich dort ablege, wenn die Daten irgendwie in die CMS Seiten eingebaut werden, können die anderen User Inhalte auf der Seite einfügen oder verändern. Kein schöner Gedanke...

Nun könne man auf die Idee kommen, SHA-Checksummen für jede Datei in die DB zu schreiben. Dann kann man Manipulationen ausschließen.
Effektiver als die Daten direkt in die DB zu schreiben, ist das aber IMHO nicht. Ich muss sicherstellen, das man an die Dateien über keinen Umweg kommen kann. Sie müssen immer durch mein Skript laufen, welches die SHA Checksumme überprüft und erst nach erfolgreicher Prüfung die Daten "freigibt". Also ziemlich unpraktikabel.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Montag 9. Juli 2007, 10:19

Mal eine Frage, wie sicherst du eigentlich die DB Zugangsdaten ab, so das du sie lesen kannst jedoch kein anderer Benutzer mit den selben Rechten und der selben Kennung? ;)
Benutzeravatar
jens
Moderator
Beiträge: 8483
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Montag 9. Juli 2007, 10:52

Guter Einwand!

Jeder User auf einem Shared-Webhosting bekommt einen eigenen DB Account.

OK, die Daten stehen im Klartext in der config.py und wenn diese lesbar für alle ist und jemand den kompletten Pfad weiß, müsste er eigentlich mit den Zugangsdaten die DB manipulieren können :?

Wenn der Webserver und damit das Skript als nobody bzw. www-data läuft muss die settings.py auch leserechte für alle haben :?

Wenn das alles so stimmt, spielt es eigentlich keine Rolle, ob es ein Verzeichnis gibt mit Schreibrechte für alle. Wie man es dreht und wendet, ohne suexec wird es nicht sicher.

Also auf der einen Seite, kann ein lokaler Angreifer Daten in der DB ändern, was nicht nett ist.
Auf der anderen Seite kann allerdings ein Angreifer z.B. MP3 Dateien einfach in ein Verzeichnis packen und jeder kann via Apache diese aus dem Web runterladen.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Montag 9. Juli 2007, 14:25

Also auf der einen Seite, kann ein lokaler Angreifer Daten in der DB ändern, was nicht nett ist.
Ein gewisses Rest Risiko besteht immer. Egal, wie du es drehst und wendest.

Ich weiche von meiner Meinung nicht ab, das *ein* Verzeichnis für Statische Dateien, wie Bilder usw. einfach beschreibbar sein darf.

Wie schon bei der settings.py angesprochen, gibt es auch hier Einschränkungen, die die Sicherheit gefärden. 100%ige Sicherheit gibt es einfach nicht. Damit muss man sich abfinden.


Ich hätte aber noch eine andere Idee:

Zwei Verzeichnisse schreibbar machen: Einmal `config` und einmal `media`. Letzteres, für die Statischen Dateien. Ich denke mal, da führt kein Weg drum herum.

In `config` werden die DB Zugangsdaten und einige andere Sachen gespeichert. Allerdings auf zwei Weisen:
Wenn keine spezielle config angegeben wurde, reagiert der Installationsmanager darauf und fragt die entsprechenden Daten in die Konfigurationsdatei ein. Verschlüsselt. via md5 oä währe es quatsch, da die Daten noch lesbar sein müssen.
(man nehme base64 oder ähnliches)
Es geht auch nur um die Lokale Sicherheit. Wenn jemand von außen auf die Konfigurationsdateien kommt, gibts da nicht wirklich ne Abwehr gegen.
Ist alles eingetragen, werden die Daten automatisch einfach nur noch verschlüsselt.

Viel Sicherer wird es dadurch nicht, komme was wolle.


Am sichersten ist es halt, so, wie es ist, nur der statische Ordner freigegeben und fertig. Um das Problem mit der settings.py bei speziellen Benutzerrechten, führt ansich kein Problem drum rum. Wie auch, denn PyLucid muss auf die Daten ja zugreifen.

MfG EnTeQuAk
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Montag 9. Juli 2007, 14:59

Hallo!

Ich fasse es mal für mich zusammen:
Das suexec des Apachen ist die einzige Möglichkeit für das Programm, etwas ins Dateisystem schreiben zu können, ohne dass andere Mitbenutzer des Servers auch schreibend auf den Ordner zugreifen können. Genau dafür wurde suexec geschaffen. Und so lange nicht jeder Benutzer in sein eigenes Jail eingeschlossen ist, wird man kaum eine andere Alternative finden.

Es ist natürlich Pech, wenn man nur über einen FTP-Account verfügt, ohne auch als Benutzer im System registriert zu sein. Dann gibt es natürlich auch keinen Benutzer, den man an suexec übergeben könnte.

Wenn ich falsch liege, dann korrigiert mich bitte.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Antworten