Re: verschlüsseltes Verzeichnis per NFS

Am Montag, den 16.07.2012, 17:51 +0200 schrieb Oliver Fromme:
> Marc Santhoff <M.Santhoff(at)web.de> wrote:
> > ich beschäftige mich gerade mit verschlüsselten Containern mit geli.
> > Welche anlegen und benutzten klappt lokal auch gut.
> >
> > Am liebsten würde ich einen solchen per NFS freigeben, der aber nur dem
> > Nutzer präsentiert wird, wenn er 1. das Passwort kennt und 2. die
> > passende Key-Datei bereitstellt - USB-Stöpsel oder so. Gibt es zu sowas
> > womöglich ein How-To oder weiß jemand aus Erfahrung, ob sowas zu
> > realisieren ist?
> >
> > Im Moment ist mein Problem, daß der mount-Vorgang erstmal ein Passwort
> > abfragen und die Schlüsseldfatei anfordern soll. Das müßte allerdings
> > von "überall" möglich sein, also ein Skript auf dem Client-Rechner ist
> > keine besonders gute Idee ...
> >
> > Die nächste schon sichtbare Baustelle ist die Übertragung über die
> > Leitung, die soll nicht im Klartext erfolgen.
>
> Eine fertige Lösung kenne ich leider nicht.
>
> Ich würde es mit folgendem Ansatz versuchen: Der NFS-Server
> exportiert nicht das eigentliche Dateisystem, sondern nur
> ein Image davon (d.h. eine einzelne, große Image-Datei).
> Dieses Image enthält eine GELI-verschlüsseltes Dateisystem.
> Der Vorteil ist, dass kein Klartext über die Leitung geht.
>
> Auf dem Client importierst Du die Datei, erzeugst daraus mit
> »mdconfig -f <imagedatei>« ein Device (mit ggatel würde es
> auch gehen), und das sollte dann ganz normal mit geli(8)
> initialisiert bzw. attacht werden können. Da GELI auf dem
> Client läuft, musst Du den Key clientseitig bereithalten.
> In der Manpage von ggatel(8) ist ein Beispiel, das aus einer
> Floppy ein GBDE-verschlüsseltes Dateisystem macht. Genau so
> würde es auch funktionieren, nur dass Du anstelle von
> /dev/fd0 die importierte Image-Datei verwendest, und GELI
> anstelle von GBDE.

Aha sehr interessant, "normales" NFS für die Containerdatei und geli
läuft auf dem Client - das gefällt mir sehr, ist überschaubar und
fordert keine Klimmzüge in Form von außergewöhnlichen und womöglich
nicht unterstützten Konfigurationen. :)

Das probiere ich jedenfalls aus, mal gucken, wie es sich über NFS
"anfühlt". Wenn kein Unterschied wäre das schon perfekt. Ich wollte zwar
die Konfiguration auf dem Server halten, aber solange nur Bordmittel
begraucht werden, keine speziellen Skripte o.ä. ist das zu verschmerzen.

> Es gibt nur zwei Punkte, die man beachten sollte: Erstens
> darf man das Device keinesfalls auf zwei verschiedenen
> Clients gleichzeitig mounten.

Klar, ja. Glücklicherweise handelt es sich um personenbezogene und
-bessene Daten, also ein COntainer pro Kopf. Aber es müssen schon
Vorkehrungen getrofffen werden, man weiß ja nie ...

> Zweitens erfordert diese
> Vorgehensweise, dass der NFS-Server das Image pauschal an
> alle potentiellen Clients exportiert. Das ist nicht so
> besonders schön, auch wenn es verschlüsselt ist. Man
> könnte sich natürlich ein kleines Skript schreiben, das
> man per ssh auf dem Server aufruft und das den Export dann
> nur für den jeweiligen Client freigibt. Erfordert ein
> bisschen Gebastel, ist aber machbar.

Hmm, Gebastel ist in diesem Fall nicht so erwünscht, aber im internen
Netz das Image zu exportieren wäre OK. Muß ich nochmal gucken wie das
mit Remote-Zugriff tatsächlich aussieht.

> Eine Alternative wäre vielleicht auch ggated + ggatec
> anstelle von NFS, um das Device zu exportieren. Das hat
> etwas weniger Overhead, und man kann es bei Bedarf durch
> ssh tunneln, wenn man paranoid genug ist (bei NFS geht
> das nicht ohne weiteres).

Kenn' ich überhaupt noch nicht, guck' ich mir an.

> Ich könnte mir vorstellen, dass jemand schonmal sowas
> gemacht und im Web dokumentiert hat, aber wie gesagt, mir
> ist bisher nichts bekannt. Vielleicht fördert Google ja
> ein Kochrezept zutage, wenn man die richtigen Fragen
> stellt. Ansosten kommt man um ein wenig Gebastel wohl
> nicht herum.

Klar, erstmal die Baustelle einzäunen, dann detailliert suchen - wenn
ich weiß, was es werden soll

Erstmal vielen Dank, damit habe ich doch schon Ansätze damit umzugehen.

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message