Userechte: Dateien ins Dateisystem speichern...

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

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???

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

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

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.

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:

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
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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.

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

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:

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

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

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:

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
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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.

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:

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
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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.

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

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:

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.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

An dieser Stelle muss ich zugeben ist das Sicherheitskonzept von PostgreSQL ziemlich gut ausgedacht: es nutzt keine Passwörter sondern Identifiziert den User über sein Login.

Meine Konfiguration:
  • execrap (so etwas wie suEXEC nur eben für Lighttpd) lässt alles was über FastCGI läuft im Kontext des Users ``django`` laufen.
  • Django läuft nun als User ``django`` und kann ohne jegliche Passworte auf die PostgreSQL-Datenbank zugreifen.
Auch wenn es nicht unbedigt sonderlich leicht aufzusetzen war wenn man es zum ersten mal macht und eher Passwort-Authentifikation ala MySQL gewöhnt ist so muss ich zugeben, dass die Koniguration doch gar nicht so übel ist. Optimal wäre es noch mit SELinux den Rest abzusichern, aber das ist eine Sache die noch warten kann.

Es ist eben so, dass wenn man anständige Sicherheit haben will, man auch eine anständige Konfiguration braucht. Deswegen finde ich den Weg irgendwelche zusätzliche Sicherheit durch Checksummen etc. einzuführen relativ labil und umständlich.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
EnTeQuAk
User
Beiträge: 986
Registriert: Freitag 21. Juli 2006, 15:03
Wohnort: Berlin
Kontaktdaten:

Es ist eben so, dass wenn man anständige Sicherheit haben will, man auch eine anständige Konfiguration braucht. Deswegen finde ich den Weg irgendwelche zusätzliche Sicherheit durch Checksummen etc. einzuführen relativ labil und umständlich.
Es geht hier ja Hauptsächlich darum, wie man eine Webapplikation, die auf einem shared webspace liegt so sicher wie möglich machen kann, mit oben genannten Problemen, das man gerne einen Ordner haben möchte, der Schreibrechte benötigt, dies aber eventuell umgehen möchte, sollte dies ein zu hohes Risiko darstellen.

Wer das Glück hat, wie du (oder ich) einen eigenen Root-Server (oder vServer) zu haben (ich denke mal, das hast du oder?), der kann sich so oder so selber absichern, was bei einem Webhoster nur durch diesen selber möglich ist.

Nur kann man denke ich kein Suexec voraussetzen. Auch, wenns mehrere haben. Noch lange nicht alle.

Aber mahl die ehrliche Frage: Wie unsicher ist es denn nun, einen ORdner nur, für Statische Dateien, wie Bilder etc. schreibbar zu machen?
Was soll groß passieren?


MfG EnTeQuAk
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

EnTeQuAk hat geschrieben:Es geht hier ja Hauptsächlich darum, wie man eine Webapplikation, die auf einem shared webspace liegt so sicher wie möglich machen kann, mit oben genannten Problemen, das man gerne einen Ordner haben möchte, der Schreibrechte benötigt, dies aber eventuell umgehen möchte, sollte dies ein zu hohes Risiko darstellen.
Eine Sicherheit vorzutäuschen die nicht durch Sicherheitsexperten eingehend geprüft wurde sondern nur auf theoretischen Überlegungen (und seinen sie auch noch so gut gemeint und durchdacht) basiert haöte ich für ein ebensolches Sicherheitsrisiko. Man sollte lieber den Usern sagen, dass die Server in einer unsicheren Konfiguration laufen und dass sie die Provider bitten sollen, da was dran zu ändern. Eine do-it-yourself-Lösung bietet hingegen eine gute Ausrede um nichts an der Situation zu änbdern, sondern sich auf solch eine Sicherheit zu verlassen.
EnTeQuAk hat geschrieben:Wer das Glück hat, wie du (oder ich) einen eigenen Root-Server (oder vServer) zu haben (ich denke mal, das hast du oder?), der kann sich so oder so selber absichern, was bei einem Webhoster nur durch diesen selber möglich ist.
Eben. Und da das Problem auf seiten der Webhoster liegt, sollte es auch von diesen korrigiert werden, statt das Problem auf andere abzuwälzen. Seien es nun die Entwickler, die etwas programmieren müssen, was suEXEC mangelhaft zu ersetzen versucht oder User die dann eben gehackte Webapps haben.
EnTeQuAk hat geschrieben:Nur kann man denke ich kein Suexec voraussetzen. Auch, wenns mehrere haben. Noch lange nicht alle.
Python kann man auch nicht vorraussetzen. Rails konnte man vor kurzem auch nicht mal erwähnen. Aber es hat sich herausgestellt, dass User nach sowas fragen und es gibt auch Hoster die sich eine gute Reputation verdient haben, indem sie eben auf die Wünsche der Kunden eingehen und durch Mund-zu-Mund-Propaganda (nicht zu unterschätzen!) mehr und mehr Kunden bekommen haben. Die Provider muss man aber nun leider oft zu etwas zwingen. In denke darüber habe ich in ähnlichem Kontext schon mal geschrieben.
EnTeQuAk hat geschrieben:Wie unsicher ist es denn nun, einen ORdner nur, für Statische Dateien, wie Bilder etc. schreibbar zu machen?
Was soll groß passieren?
Goatse. Finden Firmenkunden die deine Seite ansurfen nicht so lustig.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Quash
User
Beiträge: 9
Registriert: Donnerstag 5. Juli 2007, 01:53

Mephisto hat geschrieben:
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?
Sorry, das sollte eigentlich das Argument sein. Nochmal:
Ich finde es falsch, einen Sicherheitsmechanismus einzuführen und dann eine (weitere) Möglichkeit hinzuzufügen, um dort wieder auszubrechen.
Antworten