Wie kann man ein verschlüsseltes File als "Filesystem" mounten ?

serie300

Well-Known Member
Ich möchte bei FreeBSD (z.B. ein File auf einem Backup Dateisystem ) ein oder mehrere verschlüsseltes Files haben (neben anderen Files im selben File System), die ich als File-System zum Lesen und Schreiben mounten kann. Und das mit Bordmitteln (man will's ja vielleicht auch in 10 Jahren oder auf einem anderen Rechner wieder einsehen können).
In Pseudo-Code also sowas:
mount -t ufs -file -password "1234" "/mnt/Mein_USB_Stick/Geheimes_File" "/mnt/data"

"/mnt/Mein_USB_Stick/" ist z.B. ein vorher gemounteter USB-Stick.
Mir ist aber nicht klar, wie ich da ansetzen muß. Einer eine Idee ?
VeraCrypt ist mir bekannt und ZFS will ich mal außen vor lassen.
 
Ohne jetzt die genauen Befehle einzeln aus dem Kopf zu kennen (siehe hier Manpages oder frag ne KI):

Mit losetup kannst du aus einem File ein Blockdevice erzeugen.
Das kannst du dann mit geli verschlüsseln.
Und darauf ein FS erstellen und ganz normal mounten.
Sind alles Boardmittel.


Ob das in 10 Jahren mit Boardmitteln wieder funktioniert - man weiß es nicht, ich hab hier in einem Thread vor 1 oder 2 Jahren ziemlich gerantet, da ein aktuelles geli manche Algorithmen, die ich vor 10 Jahren verwendete, plötzlich nicht mehr unterstützte - und ich ein uralt FreeBSD irgendwie organisieren musste. Was dann andere Probleme hatte.

Daher: Backups und Archive sind etwas, was man pflegen muss.
 
Ich finde das nicht besonders elegant, aber rein mit Bordmitteln und wahrscheinlich auf die kommenden Jahrzehnte problemlos wieder auslesbar wäre eine Lösung mit mdconfig. Du erstellst die zu verschlüsselnde Datei mit truncate -s +20G /deine/datei.img und machst daraus mit mdconfig /deine/datei.img ein Device. Der Devicename wird durch das Kommando zurückgegeben. Das kannst ganz normal mit geli init ... in ein mit GELI verschlüsseltes Device konfigurieren, das jederzeit mit geli attach ... öffnen und mit mount mounten. Nach dem unmount kannst du es per geli detach ... schließen und mit mdconfig -du $DEVICE das Device zerstören.
 
Ob das in 10 Jahren mit Boardmitteln wieder funktioniert - man weiß es nicht, ich hab hier in einem Thread vor 1 oder 2 Jahren ziemlich gerantet, da ein aktuelles geli manche Algorithmen, die ich vor 10 Jahren verwendete, plötzlich nicht mehr unterstützte - und ich ein uralt FreeBSD irgendwie organisieren musste. Was dann andere Probleme hatte.
Okay, das ist definitiv ein guter Punkt, an den ich gar nicht gedacht hatte.
 
I've recently begun porting EncFS to Rust as a way to learn Rust, which turned out to be easier than I'd expectedwith the help of modern-day developer tooling.

Klingt für mich ja ein bisschen nach "Ich lass mir von ner KI den alten Code in Rust übersetzten und mal gucken was rauskommt" - naja, für 0815 Sicherheitsbelange wie "Wenn Einbrecher meine Platten klauen" wirds wohl reichen, ernsthaft vertrauen würd ich erstmal nicht darauf (auch das alte encFS hatte ja schon Probleme mit der Sicherheit für manche Szenarien). Aber da weder FUSE+encFS im Basesystem sind, ists wohl eh nicht relevant für OP.
 
Danke für die Unterstützung.
ZFS wollte ich nicht , da dann noch ein komplexer Layer. und bei Linux habe ich schon viele Dateisysteme kommen und gehen gesehen.

'losetup' war mir nicht bekannt. Im Effekt für mich im Moment aber ähnlich mdconfig. Ein "Disk Image" wird gemounted. Mit Geli kann das dann bearbeitet werden. Ich muss das beides mal ausprobieren. Problematisxh auf die die Langzeit scheint die verschlüsselung zu sein, die nicht mit Standard gpg läuft.

Muss ich nochmal abwägen, evtl. doch tar und gpg.
 
Ehrlich gesagt - wenn es wichtige Daten sind, und ich verschlüsselung will geht nichts über regelmäßiges umkopieren mounten, prüfen.

Das ist an der stelle in der Kombination Langzeit + Verschlüsselung alternativlos. Schon allein weil man regelmäßig prüfen möchte ob man noch den richtigen Key/Phrase zugriffsfähig abgelegt hat, aber auch aufgrund der tendenziellen gefahren durch die Kombination.

Entweder mit UFS (oder ext4 oder so) oder zfs, zfs hat AFAIK den charmanten Vorteil das man bitrot erkennen kann, weshalb es vermutlich eher meine wahl wäre.

Wenn "langzeit und ich fass es nie wieder an" das wichtigere Szenario ist würde ich ohne verschlüsselung klassisches Tar oder ufs / ext4 nutzen - beides gleichzeitig ist imho harakiri
 
Danke für die Unterstützung.
ZFS wollte ich nicht , da dann noch ein komplexer Layer. und bei Linux habe ich schon viele Dateisysteme kommen und gehen gesehen.

'losetup' war mir nicht bekannt. Im Effekt für mich im Moment aber ähnlich mdconfig. Ein "Disk Image" wird gemounted. Mit Geli kann das dann bearbeitet werden. Ich muss das beides mal ausprobieren. Problematisxh auf die die Langzeit scheint die verschlüsselung zu sein, die nicht mit Standard gpg läuft.

Muss ich nochmal abwägen, evtl. doch tar und gpg.

gpg gibts schon lange, und die aktuellen Defaults sind auch sinnvoll. Aber das heißt nicht, dass ein vor 15 Jahren erstelltes Archiv mit zB sha1 und 3des noch so geil ist (beides Beispielalgorithmen - immer noch unterstützt, auch zum createn, haben deutliche Schwächen), und man es nicht vielleicht auf aktuelle defaults adaptieren sollte. Post Quantum secure ist zumindest der asymetrische Part bei gpg ebenfalls nicht.
Ich versuche seit einiger Zeit von gpg auf age umzustellen. Kommt von einem namhaften Kryptologen, ist PQ-Secure und noch dazu verdammt schnell. Bis alles wirklich auf PQ gestellt ist, dauert es sowieso noch 5-10 Jahre. Besser früh beginnen.
 
Die Frage wurde ja schon beantwortet. Deshalb möchte ich darauf nicht wirklich eingehen und nur ein wenig ketzerisch dazu bemerken:
zehn Jahre ist ja nicht wirklich lang, aber immerhin lange genug, dass die USA damals innerhalb dieser Zeit eine Mondlandung hinlegen konnten
Es kann also innerhalb von einem Jahrzehnt sehr viel passieren und wer weiß schon, ob es dann FreeBSD überhaupt noch gibt.
Diese Sorge fällt ja unter die bereits gegebenen Hinweise, dass man lieber nicht Daten für lange Zeit einfach wegsperren sollte.
Neben mehrfachen und unabhängigen Kopien sollte man dann vielleicht auch ein kleines, heute aktuelles System, womöglich sogar mit einer kleinen, passenden HW zum Booten desselben, zusätzlich zu den Daten gut wegschließen.

An weitere Weltuntergangs-Szenarien will ich nicht denken. Irgendwo hört die Vorsorge ja auch auf, denn wenn einem der Himmel auf den Kopf fällt, sind ja bekanntlich eh alle Spatzen gefangen.
 
Wenn ich das mit dem Loop-back device richtig verstehe, kann man dann ja immer noch die Datei mit dd auf ein Speichermedium schreiben und dieses mounten. Die Datei ist ja ein Festplatten Image (Block 0, Block 1, ... ). Problem ist dann die Geli Verschlüsselung, die man nachbilden müßte.
 
Prinzipiell ja. Aber vielleicht magst ja mal beschreiben, was du im Detail vorhast? Wie @CommanderZed schon treffend formuliert hat, Verschlüsselung + Accessability über Jahre ohne Gedanken daran - das gibts nicht wirklich. Klar im privaten Bereich wenn mans nicht so genau nicht.. Aber ehrlicherweiße ist Archivierung (Verschlüsselt und auch nicht) immer ein Prozess. Nicht ein Tool.
 
Aber ehrlicherweiße ist Archivierung (Verschlüsselt und auch nicht) immer ein Prozess. Nicht ein Tool.
nochmal ketzerisch: Langzeit-Archivierung UND Verschlüsselung schließen sich quasi aus, zumindest aus philosophischer Sicht.
Wobei zehn Jahre nun ja nicht wirklich ein Langzeit-Szenarium bedeutet, denn hier geht es ja darum, Daten für "eine Welt nach uns" zu erhalten und dann den Nachkommen auch verfügbar zu machen.

Du kannst zB mit dd eine Datei mit lauter Nullen erstellen, dann mit mdconfig eine Gerätedatei zuweisen, anschließend dieses Pseudo-Gerät ganz wie ein gewöhnliches Speichermedium behandeln, formatieren, Dateisystem anlegen, verschlüsseln, mounten, Daten hin kopieren, Daten löschen etc.
Das ist im Grunde genommen der Vorschlag von @Yamagi, wie ich das verstehe, nur nutzt er truncate, was ich (noch) nicht kenne.

Die Dateisystem-Verschlüsselung ist insofern gefährlich, weil eben nicht so sicher ist, ob man diese mit einem zukünftigen, fremden System dann aufsperren kann. Das ist ja die Problematik von heute, dass beinahe jedes OS seine eigene Verschlüsselungs-Strategie fährt und diese nicht austauschbar sind.
Insofern hat ein Verschlüsselungsmechanismus, der auf allen gängigen Systemen läuft, vielleicht etwas mehr Zukunft in sich und hier bietet sich dann die Verschlüsselung einzelner Dateien an, wenn diese keine Mammut-Dateien sind. Und da wiederum macht man wohl keinen Fehler, GPG zu nutzen, statt womöglich einen der schnelleren, aber nicht so weit verbreiteten Algorithmen.
Dazu muss aber dann immer noch das Dateisystem in zehn Jahren bekannt sein und genutzt werden., zumindest abwärtskompatibel bleiben.

NTFS ist vielleicht das beste Beispiel für so etwas, denn es ist schon sehr lange vorhanden und immer noch (afaik) abwärtskompatibel. UFS ist so ähnlich, aber ich würde nicht über die Brücke gehen, dass du heute mit einem FreeBSD oder OpenBSD noch die Dateisysteme aus der Anfangszeit wirklich (rw) mounten kannst.
Du erwähnst ja TAR und das vermeidet das Problem der inkompatiblen Dateisysteme, bringt unter Umständen (was man aber im Griff hat) eine Kompression mit sich, die dann vielleicht nicht mehr verstanden wird.

Deshalb halte ich meinen Tip, doch ein nun gültiges OS ebenfalls zu archivieren, aufrecht. Etwa Nomad-BSD auf einen Stick oder so (und womöglich die Datei dann ebenfalls darauf). Auch ein einfaches Memstick-Img kann dazu genügen und erhöht die Sicherheit, im Zukunft noch an die Daten zu kommen.
 
Muss ich nochmal abwägen, evtl. doch tar und gpg.
Das wäre zumindest relativ langzeitstabil.
Noch als Idee dazu:
Via tarfs wäre es auch mountable. Theoretisch könnte man da via GEOM ein Encryption-Layer (geli ?) drüber legen und sich so was basteln.
Das würde zumindest die Forderungen mountable und FreeBSD-Bordmittel erfüllen.

ZFS wollte ich nicht , da dann noch ein komplexer Layer.
Das stimmt zwar einerseits.
Andererseits ist das halt auch auf mehreren Plattformen verfügbar.

Was mir grad noch spontan einfällt:
restic hat auch eine mount-Option. Und als Backup-Programm ist dabei Langzeitkompatibilität ein wichtiges Projektziel.
Bietet Verschlüssung.
Aber ist natürlich nicht mehr FreeBSD-Bordmittel.
 
Die Dateisystem-Verschlüsselung ist insofern gefährlich, weil eben nicht so sicher ist, ob man diese mit einem zukünftigen, fremden System dann aufsperren kann.
Dazu kann man noch einen Punkt ergänzen:
Also ja. Verschlüsselung kann natürlich irgendwann nicht mehr funktionieren, weil man kein funktionstüchtiges Tool mehr dafür hat.
Das kann aber auch nicht mehr funktionieren wegen Datenkorrumption. Ein einzelnes gekipptes Bit kann (ähnlich wie bei Kompression) verheerende Auswirkungen haben. Backup wird dadurch noch mal sehr viel wichtiger als ohnehin schon.


eine Kompression mit sich, die dann vielleicht nicht mehr verstanden wird.
Ergänzung/Klarstellung: Wobei man tar ja nicht komprimieren muss. Und dann gehört auch nicht mehr viel dazu es "auszulesen", selbst wenn es kein "untar" gibt.
 
Prinzipiell ja. Aber vielleicht magst ja mal beschreiben, was du im Detail vorhast?
Was ich vorhabe:
Ich mounte ein (Backup) Speichermedium und kopiere mit 'pax -rw' einfach aus /home/MeinHome drauf (und drüber). Das Verzeichnis "Mail" wird auch gemounted aber verschlüsselt und dort wird dann der Inhalt des /home/MeinHome/Mail Verzeichnis reinkopiert. Mir ging es weniger darum, das auch für Profis unknackbar zu machen, sondern "Nicht-Leserlich" für Normale (wobei was da mit KI Werkzeugen kommt ...). Und ein File wollte ich, weil das einfach kopierbar ist (Rechte, Sonderzeichen, ...) und überprüfbar (Hash).
Und es geht ja mit Bordmitteln; mir war nur nicht klar wie. Wobei das mit Geli wieder proprietär ist.
Und desweiteren gilt ja: Wissen ist besser als Nicht-Wissen.
 
Was ich vorhabe:
Ich mounte ein (Backup) Speichermedium und kopiere mit 'pax -rw' einfach aus /home/MeinHome drauf (und drüber). Das Verzeichnis "Mail" wird auch gemounted aber verschlüsselt und dort wird dann der Inhalt des /home/MeinHome/Mail Verzeichnis reinkopiert. Mir ging es weniger darum, das auch für Profis unknackbar zu machen, sondern "Nicht-Leserlich" für Normale (wobei was da mit KI Werkzeugen kommt ...). Und ein File wollte ich, weil das einfach kopierbar ist (Rechte, Sonderzeichen, ...) und überprüfbar (Hash).
Und es geht ja mit Bordmitteln; mir war nur nicht klar wie. Wobei das mit Geli wieder proprietär ist.
Und desweiteren gilt ja: Wissen ist besser als Nicht-Wissen.

Wenn du das regelmäßig (Täglich, wöchentlich oder monatlich) machst, hast du ja einen Prozess, der dein Tooling immer wieder testet. Somit sollte eigentlich alles hier erwähnte (loopback Device, darauf GELI) oder auch externe Dinge wie restic sicher nutzen lassen. Sollte es ein Tool nicht mehr geben, sollte eine Entwicklung einschlafen, oder sollten sich Defaults ändern: Du merkst es sofort und kannst gegebenenfalls deine Backups anpassen und umschreiben. GELI ist natürlich nicht proprietär, das ist offen und von BSD entwickelt.

Edit: Ich würd in deinem Fall tatsächlich der Einfachheit halber restic verwenden. Und zwar das ganze Home in ein verschlüsseltes restic Repo. Ist einfach zu benutzen (quasi nur ein Backup Befehl), automatisches Aufräumen wenn gewünscht (zB "Behalte 1 Monatliches Backup + die letzten 5, lösche den Rest), Restore uA über einen Mount möglich.
Solltest du merken, restic hat ne inkompatiblie Änderung, wird nicht mehr für FreeBSD entwickelt oder ähnliches: Backuptool wechseln. Sowas passiert ja nicht von Heute auf Morgen.
 
Zurück
Oben