Gibt es für Linux-Server ein verschlüsseltes Dateisystem, dessen Daten auf den Clients ver- und entschlüsselt werden und der Server über keine Informationen zu Struktur und Schlüssel dieses Dateisystems verfügt?
über keine Informationen zu Struktur Keinen Plan über die Struktur?????????????? Da bleibt nur sowas wie ISCSI oder NBD, das ist aber kein FS mehr. Ansonsten encfs oder ecryprtfs.
Klar. Jedes beliebige Dateisystem. Da liegt dann eine Datei mit einem verschlüsselten Dateisystem drin (LUKS?). Der Server exportiert die Datei (SMB, NFS, was auch immer), die Clients mounten das Dateisystem darin.
enc schrieb: > Stefan Rand schrieb: >> die Clients > > Mehere Clients gehen nich mit gwöhnlichen Filesystemen. Das "äußere" Dateisystem ist egal, ausgeliefert wird per SMB oder NFS oder so. Das "innere" Dateisystem kann nicht mit mehreren gleichzeitigen Zugriffen umgehen? Sag das schnell allen Multi-User-Betriebssystemen. Mehrere gleichzeitig eingeloggte Benutzer sind auch nichts anderes als Clients.
Stefan Rand schrieb: > enc schrieb: >> Stefan Rand schrieb: >>> die Clients >> >> Mehere Clients gehen nich mit gwöhnlichen Filesystemen. > > Das "äußere" Dateisystem ist egal, ausgeliefert wird per SMB oder NFS > oder so. > > Das "innere" Dateisystem kann nicht mit mehreren gleichzeitigen > Zugriffen umgehen? Sag das schnell allen Multi-User-Betriebssystemen. > Mehrere gleichzeitig eingeloggte Benutzer sind auch nichts anderes als > Clients. Falsch, wenn mehrere Benutzer gleichzeitig auf ein Dateisystem auf dem selben Volumen zugreifen hat das OS das unter Kontrolle. Wenn aber verschiedene Clients direkt den Zugriff auf ein Volumen wollen, müssen die Zugriffe synchronisiert werden, da die Dateisysteminformationen konsistent bleiben müssen. SMB, NFS sind Netzwerkdateisysteme, die den Zugriff abstrahieren und damit die Kontrolle über das absolute Dateisystem dem Server überlassen. Damit wird die Konsistenz und das Locking von Dateien sichergestellt. Daher ist es schwer Serversysteme mit mehrfachem Client Zugriff vollständig zu verschlüsseln ohne das der Server etwas von den Daten weiß. Eine Möglichkeit wäre, jeder Client bekommt vom Server ein eigenes Volumen mittels iSCSI zugewiesen und verschlüsselt, bzw verwaltet dieses selber. Dann kann darüber aber kein gemeinsamer Datenaustausch erfolgen. Eine zweite Möglichkeit wäre, das Servervolumen wird mit LUKS verschlüsselt und das Dateisystem vom Server verwaltet und mittels NFS4 oder CIFS verschlüsselt den Clients angeboten. Dann wäre zwar die Datenhaltung und der Transport verschlüsselt, die Daten liegen aber für alle berechtigten Clients oder Nutzer ohne Verschlüsselung offen da. Das Problem hierbei ist einfach, das LUKS, Bitlocker oder TrueCypte Blockverschlüssler sind. Die können wunderbar auf Volumen angewandt werden, das dann später mit einem Dateisystem versehen wird. Für die Einzeldateiverschlüsselung eigenen sich diese nicht. Da werden Verschlüsselungstechniken auf Dateiebene benötigt. Unter Windows 2003/2008/2012 gibt es hierfür EFS, das von entsprechenden Clients mittels CIFS verwendet werden kann. Unter Linux würde sich hier Ecryptfs anbieten. Das Problem bei EcryptFS ist, dieses über Samba oder NTFS4 an die Clients weiter zu reichen. aber vielleicht hilft ja das hier: http://www.linux-magazin.de/Ausgaben/2011/06/Bitparade/%28offset%29/2 http://www.wcm.at/forum/showthread.php/ecryptfs_problem_mit_samba_und_gro_en_dateien-247034.html?s=dbc482890da2f19378b7f5f39a12e47a&
:
Bearbeitet durch User
Marek Walther schrieb: > Falsch, wenn mehrere Benutzer gleichzeitig auf ein Dateisystem auf dem > selben Volumen zugreifen hat das OS das unter Kontrolle. Wenn aber > verschiedene Clients direkt den Zugriff auf ein Volumen wollen, müssen > die Zugriffe synchronisiert werden, da die Dateisysteminformationen > konsistent bleiben müssen Na wenigstens einer, der das Problem erfaßt hat ;-) Um sowas realisieren zu können, müßte der FS-Treiber auf dem Server blockweises Locking und Semaphore zur Verfügung stellen und Primitiv-Operationen für die Freispeicherverwaltung, über die die Clients dann darauf arbeiten können. Sonderlich effezient würde das Ganze wohl nicht, aber wenn nur selten geschrieben werden muß, wäre das nicht so schlimm. In so einem FS könnte man es jedenfalls eher wagen, sensible Daten auf einem externen Server zu halten, als in den üblichen Cloud-Systemen. > Dann wäre zwar die Datenhaltung und der Transport verschlüsselt, die > Daten liegen aber für alle berechtigten Clients oder Nutzer ohne > Verschlüsselung offen da. Das bekommt man leicht über ssh, aber die Konstruktion erfüllt leider nicht das, worauf es mir ankommt: daß kein Schlüssel auf dem Server vorhanden ist.
Uhu Uhuhu schrieb: > Um sowas realisieren zu können, müßte der FS-Treiber auf dem Server > blockweises Locking und Semaphore zur Verfügung stellen und > Primitiv-Operationen für die Freispeicherverwaltung, über die die > Clients dann darauf arbeiten können. > > Sonderlich effezient würde das Ganze wohl nicht, aber wenn nur selten > geschrieben werden muß, wäre das nicht so schlimm. Lesezugriffe müßen auch synchronisiert werden, es kann kann ja sein das ein anderer schreibt :-() GFS, Ceph, OCFS und Konsorten scalieren recht gut, aber der Aufwand um Split-Brain zu vermeiden ist schon recht hoch. On top von dm-crypt habe ich das noch nicht gesehen Aber encfs und ecryptfs verraten auch nicht so furchbar viel.
Einfach weiter suchen. Encrypt FS Sollte das richtige sein, ist aber fummelkram. Ich selber verwende immer dm-crypt (LUKS) auf dem Server und ntfs4. Das andere ist mir zu viel Fummelkram.
kopfkratz Ja nun was ist denn das eigentliche Grundproblem ? Man könnte auch Truecrypt Volumes als Dateien auf den Server legen und nur die Clients haben die keys dazu. PGP ginge auch oder man baut sich selber ein passendes Script das XYZ als Verschlüsselung nimmt. Da wohl alle Clients "gleichzeitig" lesen und schreiben können sollen wird es sowieso etwas sehr spezielles ... Am einfachsten wäre wohl Truecryptcontainer mit einem Roundrobin Verfahren, d.h. jeder Client kommt einmal rundherum zum Zugriff. Nur wenn Clients von den jeweiligen Daten abhängig sind wird es wieder komplizierter. Also was soll es wirklich werden glaskugelplier
Marek Walther schrieb: > Eine zweite Möglichkeit wäre, das Servervolumen wird mit LUKS > verschlüsselt und das Dateisystem vom Server verwaltet und mittels NFS4 > oder CIFS verschlüsselt den Clients angeboten. Erklärst du mal den Unterschied zu meiner Variante? Daß du ein Volume exportierst und ich eine Datei soll einen Unterschied machen? Ich zweifle.
kopfkratzer schrieb: > Am einfachsten wäre wohl Truecryptcontainer mit einem Roundrobin > Verfahren, hmh. ecnfs/ecryptfs zusammen mit unison werf ich mal in die runde.
Nach der ganzen NSA-Scheiße müßte doch eigentlich großer Bedarf nach einem Server-FS bestehen, dem man außer verschlüsselten Datenblocks nicht viel abringen kann, selbst wenn man direkten Zugriff auf den Server hat. Eine Frickellösung sollte es jedenfalls nicht sein und das mit unison ergibt keine Synchronisationsmöglichkeit für mehrere Clients.
:
Bearbeitet durch User
Unison wird nicht mehr weiter entwickelt. Du musst einen Kompromiss eingehen. 1.) Servervolumen voll verschlüsseln um dem Verlust der Server vorzubeugen. 2.) Transportverschlüsselung zu den Clients. Im Lan wäre das NFS4 oder CIFS. Ansonsten halt TLS und SSL. Bei den Sync. Tools hast du auch immer das Problem, dass die Daten schön verteilt werden, was die Sicherheit auch nicht gerade erhöht. Als Alternative für Unison werfe ich mal SeaFile in den Raum. Hier ergfolgt die Datenhaltung aber in einem Repo und in einer Datenbank. Clients sind für Windows, Linux, MacOS, iOS, Android verfügbar. http://seafile.com/en/home/ Der Comunity Server ist kostenlos und schnell installiert. Er verfügt über eine eigene Benutzerverwaltung, die aber auch über LDAP an eine bestegende Benutzerverwaltung andocken kann. Habe das bei einigen Kunden gegen das ADS gelinkt. Das Tool ist einfach cool und nicht nur ein einfacher Syncer. Ich denke das darf man sich im 21 Jahrhundert gerne mal antun. ;)
Wenn man Datenbanken verwendet wird's schwierig. Resp die Struktur kompromitiert die Sicherheit. Wenn zB in einem Feld die pdf gehalten werden...
Uhu Uhuhu schrieb: > der Server über keine > Informationen zu Struktur und Schlüssel dieses Dateisystems verfügt? Ja, /dev/null ;-) MfG,
Man könnte auch einfach Imagefiles erstellen, diese per NFS verteilen und im Client als HDD mounten. Das müsste vor der Installation geschehen so, dass man das Dateisystem auf dem Client komplett verschlüsselt. Oder wie verstehe ich die Sache? Für mehrere Clients braucht man dann eben zusätzliche Images für /home und /tmp in den RAM. Ansonsten wäre es auch möglich einfach verschlüsselte User-Verzeichnisse anzulegen und diese im Client zu mounten. Dann müssen die Keys auch nicht auf dem Server liegen. MfG
johnny schrieb: > Ansonsten wäre es auch möglich einfach verschlüsselte User-Verzeichnisse > anzulegen und diese im Client zu mounten. Dann müssen die Keys auch > nicht auf dem Server liegen. Sobald so ein Dateisystem von mehreren Clients mit Schreibberechtigung gemountet würde, wäre die Katastrophe perfekt. Deswegen werden sie üblicherweise vom Server verwaltet und die Clients schicken nur Anfragen an den Treiber auf dem Server. Man müßte auf dem Server einen Block-Treiber haben, der zusätzlich noch Blocks locken kann. Auf den Clients müßte jeweils ein Treiber laufen, der die Filesystem-Operationen auf diesem Block-Treiber übers Netz ausführt und für Ver- und Enschlüsselung zuständig ist. Das Ganze würde nicht gerade sehr effizient, aber für Daten, die selten geschrieben, aber häufig gelesen werden, wäre das akzeptabel.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.