Dropbox - bei mir läuft der Client unter KDE - synchronisiert einen vorher eingestellten Ordner mit dem Onlineservice der Firma. Die Dateien werden bei der Übertragung verschlüsselt, trotzdem kann Dropbox auf diese Dateien selbst zugreifen, da die Verschlüsselung mit Schlüsseln von Dropbox erfolgt. So weit, so schön. Das man die selbst vor der Übertragung verschlüsseln kann ist mir bekannt und um diese Dateien geht es mir nicht.
Es geht mir um alle anderen Dateien im Homeverzeichnis auf meinem Rechner. Natürlich kann nur der Eigentümer des Homeverzeichnisses auf sie zugreifen. Dropbox läuft aber genau mit den Rechten dieses Nutzers und mit diesen Rechten ausgestattet hat Dropbox alle nötigen Rechte, auf andere Dateien im Homeverzeichnis zuzugreifen. Richtig? Und würde auch in den Genuss der transparenten Entschlüsselung selbst verschlüsselter Dateisysteme kommen.
Mein Wissen über die Rechteverwaltung ist leider nur rudimentär. Kann mir das jemand erklären? Normalerweise würde ich denken, Dropbox sollte unter einem eigenen Benutzer laufen, die Dateien in den zu synchronisierenden Ordnern eben diesem Nutzer gehören und der Standardnutzer ebenfalls die Schreib- und Leserechte des Dropboxusers haben. Dropbox wäre damit verboten, auf andere Dateien als im definierten Ordner zuzugreifen.
Der Dropbox-Client ist Closed Source. Im Prinzip wäre es damit das perfekte Spionageprogramm, ein Einfaches für z.B. die NSA, Dropbox Inc. zu zwingen Code zu implementieren. Ich wüßte nicht, was den Dropboxclient dann davon abhalten sollte, auf alle meine Dateien zuzugreifen. Oder sehe ich das falsch und das ist sicher?
Danke im Voraus!
Rechte Dropbox - Sicherheit
Anmeldungsdatum: Beiträge: 165 Wohnort: Beijing |
|
Anmeldungsdatum: Beiträge: 4015 |
Hallo, ich kenne Dropbox nicht, Snowden rät davon ab.
http://www.spiegel.de/netzwelt/web/dropbox-edward-snowden-warnt-vor-cloud-speicher-a-981740.html Soweit ich das verstanden habe, können US Unternehmen zur Kooperation mit Geheimdiensten verpflichtet werden. Du kannst die Daten vor dem Upload selbst verschlüsseln. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 165 Wohnort: Beijing |
Lieber verdooft, du bist wohl auf der Jagd nach den meisten Forumsbeiträgen 😊 Alle deine Bemerkungen hatte ich schon in meinem Beitrag im ersten Absatz geschrieben. Darum geht es nicht! |
Anmeldungsdatum: Beiträge: 4015 |
Ok, hab ich überlesen. Wie soll denn der Client Sicherheit erhöhen, wenn Dropbox es serverseitig schon nicht ist (sicher)? Wenn das von dir gewünschte in Richtung entferntes Dateisystem mit Benutzerrechten geht, klingt das nach: http://de.wikipedia.org/wiki/Network_File_System Wegen
unverschlüsselten Netzwerkverkehr kann man analysieren, lokale Zugriffe (wird eine Datei ohne Anforderung geöffnet, geschrieben...) auf Dateien auch feststellen. Hast aber insofern Recht, dass ich Dropbox nicht kenne und mich jetzt lieber raushalte. 😬 |
(Themenstarter)
Anmeldungsdatum: Beiträge: 165 Wohnort: Beijing |
Ok, ich hab es wohl nicht schlau genug geschrieben... |
Anmeldungsdatum: Beiträge: 15896 |
Hallo marwell, Da es Closed Source ist kann dir diese Frage nur der Hersteller beantworten. Höchstwahrscheinlich kann der Hersteller aber auf deine Daten zugreifen .... schließlich will er ja Geld verdienen. Gruss Lidux |
Anmeldungsdatum: Beiträge: 259 |
Hallo, nur noch einmal kurz, damit ich es richtig verstehe: Deine Frage lautet, kann Dropbox auch auf andere Dateien in anderen Verzeichnissen zugreifen, die eigentlich nicht zum Sync-Ordner gehören? Kann Dropbox also die Festplatte scannen? Gruß Christoph |
Anmeldungsdatum: Beiträge: 867 |
Das siehst du alles absolut korrekt. Helfen tut dir da nur eine Rechtetrennung mit unterschiedlichen Nutzern/Gruppen. So etwas lässt sich komfortabel einrichten, kostet aber viel Zeit bei der Erstellung und setzt (sehr) gutes Verständnis der Rechteverwaltung vorraus. Es gibt im wesentlichen 3 Möglichkeiten das auf File- und Prozessebene zu erreichen: 1. die Standardrechte (rwx) http://wiki.ubuntuusers.de/Rechte 2. ACL http://wiki.ubuntuusers.de/ACL 3. das Program "bindfs" zum Spiegeln ganzer Verzeichnisstämme, maßgeschnitten auf einen Nutzer und dessen Rechte (mit Ausnahme symbolischer Verzeichnislinks) Die rwx-Rechte sind vom Grunde her einfach zu verstehen aber es gibt auch einen Teil, der schwer zu erlernen/durchdenken ist. Kennt man sich dahingehend sehr gut aus, kommt man damit auch um ACL's herum. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 165 Wohnort: Beijing |
gesi3, genau! So hätte ich das schreiben sollen.
Außerdem war in meinen Vorstellungen immer wichtig, welches Programm greift worauf zu:
Das die Could-Speicher-Programme noch viel mehr können, darauf bin ich schlicht nicht gekommen, obwohl es eigentlich klar ist. Bei der ganzen Sicherheitsdiskussion z.B. über die Dropbox, habe ich immer nur die Sicherheit der Dateien im Dropboxordner gedacht. Naiv. Ein bisschen naiv dann aber auch die Diskussionen über die Verschlüsselung der Dateien in der Dropbox. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 165 Wohnort: Beijing |
So, Dropbox deinstalliert und ppa entfernt. Auf Dropbox kann ich verzichten. Das ist natürlich keine zufriedenstellende Lösung. Im Prinzip wäre eine vernünftige Rechteverwaltung besser. Mit Skype habe ich das selbe Problem jetzt, nur leider bei mir der Standard, mit Leuten zu kommunizieren. Ich komme wohl nicht drumrum, mich genauer mit den Rechten der Programme oder ACL zu beschäftigen. Eigentlich mehr als eigenartig, dass diese Firmen alle nicht an die Sicherheit der Nutzer denken. |
Anmeldungsdatum: Beiträge: 867 |
Das ist nicht eigenartig. Eine kommerziell agierende Firma wird ihr Augenmerk immer auf die Visualisierung und Funktion ausrichten, denn das ist das Kriterium nach dem der Käufer entscheidet. (90 Prozent der Sinneseindrücke kommen über das Auge.) An der Sicherheit wird erst gearbeitet, wenn es an die Reputation geht. Dazu kommt noch das Sicherheit taktisches Denken (und damit Erfahrung) erfordert und ein Vielfaches an normaler Entwicklungszeit kostet. (Und damit dem Profitstreben entgegen steht.) Das wirst du schnell feststellen, wenn du dich damit auseinandersetzt. Aber das gute an Linux ist, dass sich alles automatisieren lässt und man, richtig gemacht, den Aufwand nur einmal im Leben hat. |
Anmeldungsdatum: Beiträge: 408 |
nur mal so als Anmerkung...man kann dropbox ohne Oberfläche laufen lassen (Daemon). genutzt wird das bei Systemen ohne X11 (reine Server). du könntest dir diese Funktionalität zu nutze machen und den Daemon "einsperren" (z.b. in eine chroot, VM [openvz,lxc,...]). somit hat er keinen Zugriff auf den Rest deines Dateisystems (zumindest nicht ohne entsprechend kriminelle Energie). Vom Host hast du (zumindest bei chroot und openvz) zugriff auf den Dropbox-Ordner und kannst die Daten auch sauber entschlüsseln (encfs, etc.) 😉 |
Anmeldungsdatum: Beiträge: 867 |
Wozu chroot und lxc? Beide Implementierungen sind unsicher, wenn der Gast als "Root" läuft. Du musst dort auch bloss auf einen anderen Account ausweichen und damit kannst du dir beides sparen. Eine echte VM (Virtualbox) empfiehlt sich nur, wenn das Programm mit Root-Rechten ausgeführt werden muss. Z.B. wenn es sich um ein Modul handelt oder Rechte besitzen muss, die über den eines normalen Accounts hinausreichen. Denn die VM bringt auch wieder zusätzliche Module mit sich, die auf Kernelebene laufen (und damit Root-Rechte besitzen) und über diese dann gegebenfalls das gesamte System angreifbar ist.
Mit einem anderen Nutzer auch nicht. |
Anmeldungsdatum: Beiträge: 408 |
Ich habe nicht gesagt, dropbox soll als root laufen...auch in der chroot kann man non-root sein, in einer openVZ sowieso
schreibend nicht, aber lesend, z.B. welche Dienste installiert sind und ggf. laufen ⇒ Angriffsmöglichkeiten viele Sachen sind als normaler User lesbar, und wenn du z.b. ein externes Laufwerk (besonders bei linux-fremden Dateisystemen) nicht nur für den jeweiligen user lesbar ist, bringt dir der andere User nichts mir ist bewusst, dass man aus der chroot und auch aus anderen Umgebungen ausbrechen kann, deswegen habe ich ja gesagt, dass eine gewisse kriminelle Energie von Nöten ist, damit dise Sicherung nicht greift...100%ige Sicherheit gibt es nicht. mich würde es nicht wundern, wenn es auch zu encfs eine Backdoor gibt, aber man muss es den Cloud-Anbietern ja nicht ganz so einfach machen |
Anmeldungsdatum: Beiträge: 867 |
Ok, das sind die zwei Dinge die man mit lxc auf Anhieb abstrahieren kann, die Prozessliste und das Netzwerk. Man kann natürlich im Systemcontainer auch die Pfade neu belegen aber das ist, gemessen am Aufwand lxc einzurichten, bedeutungslos. Man bekommt dadurch nämlich auch eine Menge Nachteile z.B. bei der Kommunikation mit Audiodevices.
Wird unter /media/<user> eingebunden. Wenn du allen Nutzern die lesen dürfen die entsprecheden Gruppenrechte gibst und diese setzt, plus "o-x" (nur auf /media/<user>), ist das Problem schon gelöst. Mit lxc wäre der Aufwand höher.
Entweder es ist sicher oder eben nicht. Ein Bewusstsein dazwischen (mit Ausnahme unbekannter Bugs) kann man nicht gelten lassen. |