Aktueller Status von Daten-Verschlüsselung

[eggy]

Laptop im Zug vergessen und du willst nicht das jemand dein Familien Bilder sieht, dann reicht doch das /home verschluesselt ist, oder nicht?

Wenn die Bilder wirklich nur in /home liegen würden, ja.
Tun sie aber je nach verwendeter Software bzw jeweiliger Konfiguration, unter Umständen, ohne dass man es mitbekommt, doch nicht.
Beispiele:
Druckserver so konfiguriert, dass es Druckaufträge ablegt, damit man sie nochmal ausdrucken kann: alle jemals ausgedruckten Sachen in /var
Photoverwaltung hat eigene Sqlitedatenbank um Thumbnails global zu speichern: alle angeschauten Bilder liegen in /var
Beliebige Software braucht installierten Datenbankserver, der legt seine Datenbanken und darin alles mögliche ab in /var
Beliebige andere Software ist so konfiguriert, dass es seine Zwischenschritte vorhält in /tmp
Homebankingsoftware speichert genutzte Verbindungsinformationen in seinen Logfiles in /var
Spoolingverzeichnisse für diverses in /var

Extra ohne konkrete Beispiele. Schau Dir einfach mal an, was bei Dir in /var landet und entscheide dann selbst, wie hoch die Wahrscheinlichkeit ist, dass da Daten dabei sind, die nicht in anderer Leute neugierige Griffel gehören.

[wanne]

Laptop im Zug vergessen und du willst nicht das jemand dein Familien Bilder sieht, dann reicht doch das /home verschluesselt ist, oder nicht?
Ist ja nicht immer gleich eine Staatliche Behörde.

Nicht mehr so bald du sie ausgedruckt hast. Dann liegen die gerne nochmal unter /var/spool, nicht wenn du mal zu wenig RAM hattest, weil dann liegt der Key fürs ecrytfs in SWAP und nicht wenn du sie im Deitmanager angeguckt hast, weil dann liegen die Vorschaubilder unter /tmp... und nicht, wenn du Photos ohne Gesicht bei Pronoplattform XY hochgeladen hast, weil dann kann man sie an den Metadaten wiedererkennen.
Man kann jetzt SWAP mit nem ephemeral Key verschlüsseln (Wie das Ubuntu bis 16.04 gemacht hat), tmp als tmpfs mounten, die Bilder nicht ausdrucken, meinen dass man so Bilder eh nie hoch laden müsste... Aber je länger man sucht desto mehr wird man finden.
Debian ist halt seit 30 Jahren gewachsen und nie wurde darauf geachtet das Daten vor Debian selbst geschützt werden müssen. Man hat halt das übliche Unix-Rechtemanagement und wenn die für fremde nicht lesbar sind war alles gut. Defakto müsstest du da halt jede Einzelkomponente nochmal neu überprüfen, wie sie sich verhält. Und das geht halt schief.

[fischig]

Sind das, was eggy und wanne angesprochen haben, nicht alles Dinge, die man entsprechend selbst regeln kann - ohne das komplette System zu verschlüsseln?

Gehe ich recht in der Annahme, dass der Inhalt von /tmp keinen Neustart überlebt?

[Lord_Carlos]

Gehe ich recht in der Annahme, dass der Inhalt von /tmp keinen Neustart überlebt?

Ich meine bei default ist /tmp heutzutage im Ram. Frueher zu DDR Zeiten war das aber noch anders.
Da hat man auch noch Drucker und swap benutzt.

[MSfree]

Ich meine bei default ist /tmp heutzutage im Ram.

Bei meinem Buster, das ich vor ein paar Monaten installiert habe, ist /tmp ein Teil der Root-Partition, und das habe ich nicht manuell so eingestellt. Auch mein als tvheadend fungierender Raspi mit Buster hat /tmp nicht als RAM-Disk (tmpfs) gemountet. Es scheint also nicht der Normalfall zu sein, daß /tmp im RAM liegt.

Frueher zu DDR Zeiten war das aber noch anders. Da hat man auch noch Drucker und swap benutzt.

[Lord_Carlos]

Komisch. Ich bin mir recht sicher das es bei mir eine tmpfs partition ist. Vielleicht weil ich auch kein swap habe?

[MSfree]

Komisch. Ich bin mir recht sicher das es bei mir eine tmpfs partition ist.

Code: Alles auswählen

mount | grep tmp

?

Vielleicht weil ich auch kein swap habe?

Ich habe auch keinen Swap eingerichtet.

[fischig]

Meine Frage war: Überlebt der Inhalt von /tmp einen Neustart? Falls /tmp im RAM liegt, dann wohl mit Sicherheit nicht. Falls irgendwo anders, sollte der Verzeichnisinhalt aber genauso wenig einen Neustart überleben - jedenfalls ging ich bisher davon aus. Was sonst soll /tmp?

[MSfree]

Meine Frage war: Überlebt der Inhalt von /tmp einen Neustart?

Ich habe den Rechner, von dem ich hier tippe, vor etwas über 3h gebootet und unter /tmp befinden sich nur Dateien heutigen Datums. Es scheint also immer mit einem leeren /tmp gestartet zu werden. Ich kann dir aber nicht sagen, ob /tmp beim Shutdown gelöscht wird oder beim Booten. Ersteres wäre eigentlich die bessere Lösung.

Naja, und bei Rechnern, die durchlaufen, ist es ziemlich egal, ob /tmp im RAM oder auf der Platte liegt. Da wird nur maximal einmal am Tag /tmp per cron gesäubert. Das gibt eventuellen Krackern genug Zeit.

[wanne]

Falls irgendwo anders, sollte der Verzeichnisinhalt aber genauso wenig einen Neustart überleben - jedenfalls ging ich bisher davon aus. Was sonst soll /tmp?

Ne. /tmp ist ein Platz wo Programme kurzzeitig Daten zur späteren Wiederverwendung ablegen. Vor allem Caches etc. Klassischerweise ein schnelle Dateisystem ohne Backup und damit ideal für sich schnell ändernde Daten. Heute eben oft im RAM. Aber eigentlich ist das eher unerwünscht, dass das jeden Neustart neu erzeugen muss. Man hat das nur des großes Speedes wegen in Kauf genommen. – Ausnahme ist Systemd gewesen, der anfangs seinen Müll nicht aufräumen konnte und deswegen kurzzeitig die Kombo tmpfs+Systemd beliebt machte.

Es scheint also immer mit einem leeren /tmp gestartet zu werden. Ich kann dir aber nicht sagen, ob /tmp beim Shutdown gelöscht wird oder beim Booten.

Das ist sicher nicht üblich. Es gab schon immer Cleanup-Scripte.

Das gibt eventuellen Krackern genug Zeit.

Löschen hilft halt nichts, weil du die Dateien direkt mit extundelete und co wieder bekommst.

[JTH]

Ich kann dir aber nicht sagen, ob /tmp beim Shutdown gelöscht wird oder beim Booten. Ersteres wäre eigentlich die bessere Lösung.

Tja, der Konjunktiv passt da leider. Es passiert natürlich erst beim Boot.

Auf nem System mit systemd sorgt systemd-tmpfiles dafür, dass diverse temporäre Ordner etc. beim Boot definitiv angelegt sind, u.a. /tmp. Das ist in /usr/lib/tmpfiles.d/tmp.conf konfiguriert. Da ist auch angegeben, dass der Inhalt von /tmp gelöscht werden soll, das passiert aber prinzipbedingt immer (und damit hier „erst“) beim Boot.

Falls gewollt, kann man in diesen tmpfiles.d-Definitionen auch ein maximales Alter für Dateien/Ordner angeben. Sie werden dann gelöscht, wenn entsprechend lange nicht mehr geschrieben & gelesen. Das könnt man auch für /tmp machen.

Auf nem System mit systemd kann man eine vorinstallierte mount-Unit benutzen, um /tmp als tmpfs zu mounten:

Code: Alles auswählen

# systemctl link /usr/share/systemd/tmp.mount

Oder natürlich nen Eintrag in der fstab.

[MSfree]

Aber eigentlich ist das eher unerwünscht, dass das jeden Neustart neu erzeugen muss.

Wenn /tmp auf der Root-Partition liegt, ist das nur ein Verzeichniseintrag, da muß gar nichts neu erzeugt werden. Wenn /tmp ein tmpfs ist, dauert es halt ein paar zehntel Sekunden, um das beim Booten anzulegen.

Es gab schon immer Cleanup-Scripte.

Das ist mir natürlich bekannt. Die Frage war aber, ob der Cleanup beim Shutsown stattfindet oder erst beim Boot. Beim Shutdown hätte man halt kein Dateieinträge mehr im /tmp-Verzeichnis. Wenn man die Platte nach dem Shutdown ausbaut, hätte man keine Dateireste.

Löschen hilft halt nichts, weil du die Dateien direkt mit extundelete und co wieder bekommst.

Das ist natürlich richtig. Wer so eine ausgebaute Platte forensich auch auf gelöschte Daten untersucht, wird hier fündig werden.

[eggy]

Die Frage war aber, ob der Cleanup beim Shutsown stattfindet oder erst beim Boot.

Früher™, vor systemd, beim Boot. Wenn ichs richtig im Kopf hab, wars nen Eintrag in der bootmisc.sh in /etc/init.d/ falls nicht, dann eins der rc scripte. Wurde am Ende vom Bootprozess abgearbeitet. D.h mit ner LiveCD kam man noch an Daten ran.
Bei systemd soll es wohl ne Variable dafür geben, bei der man setzen können soll, was wo wie wann gelöscht wird. Hab ich mich noch nicht genauer mit befasst, falls jemand noch weitere verlässliche Doku dazu findet, freu ich mich über den Link.

Überlebt der Inhalt von /tmp einen Neustart? Falls /tmp im RAM liegt, dann wohl mit Sicherheit nicht.

Jein, such mal nach "cold boot attack".

[Lord_Carlos]

Komisch. Ich bin mir recht sicher das es bei mir eine tmpfs partition ist.

Code: Alles auswählen

mount | grep tmp

Joa ist tmpfs, aber ich meinte eher das es schon default so war.

Systemd tmp.mount ist bei mir noch default und erstellt es tmp als tmpfs Wird das von einer anderen Config generiert?

[Spindoctor]

Wie ist es denn nun eigentlich mit der Hardware-Encryption moderner SSDs?

Habe bisher eher schlechtes darüber gelesen, aber vielleicht gibt es ja doch gute Implementierungen?

[wanne]

Wenn /tmp ein tmpfs ist, dauert es halt ein paar zehntel Sekunden, um das beim Booten anzulegen.

Es geht um Daten, die Programme da erzeugen. Früher waren das z.B. gerne Grafiken die erst berechnet werden und dann immer wieder verwendet werden. (3D-Scrensaver etc.)

aber vielleicht gibt es ja doch gute Implementierungen?

Vielleicht. Sogar wahrscheinlich. Die frage ist eher ob du dich auf vielleicht verlassen möchtest. Microsoft hat da lange Zeit ein Blacklist geführt. Irgend wann wurde die so riesig, dass sie es sein lassen haben und das gar nicht mehr verwenden. Praktisch jede untersuchte Platte hatte massive Mängel. Dazu kamen diverse BIOSe/EFIs, die die Keys raus tragen. Irgend wann hat man da halt aufgegeben. Das ist wie HTTP-Pipelining. Zu viele kaputte Implementierungen, als dass das irgend jemand verwenden will. Jetzt kommt halt QUIC bzw. http/3 als Alternative.

Joa ist tmpfs, aber ich meinte eher das es schon default so war.

Ich meine Installationen die als Debian 9 oder 10 installiert wurden haben das so ältere nicht.

[MSfree]

Wie ist es denn nun eigentlich mit der Hardware-Encryption moderner SSDs?

Möchtest du dich wirklich darauf verlassen?

So weit ich weiß, setzt man dazu ein Paßwort für die Platte/SSD im BIOS/UEFI. Dreimal falsch und die Platte/SSD ist permanet gesperrt. Du kannst sie nicht durch üebrschreiben mit Nullen reinitialisieren -> Elektroschrott. Eine Technik, für die es keine Möglichkeit gibt, selbst unter Verlust der Daten das Gerät wieder verwendbar zu machen, ist mir zutiefst suspekt.

Wie gut die Verschlüsselung ist, mag ich gar nicht beurteilen. Aber ich würde den Herstellern durchaus zutrauen, daß die mit Rot13 arbeiten und uns das als supersicher anpreisen.

[smutbert]

Schwächen oder Hintertüren hat es bei externen Festplatten und USB-Sticks mit Verschlüsselungsfunktionen ja bereits oft genug gegeben.

Ich habe im Repository noch etwas gefunden, was für mich so klingt, als wäre es genau das was der TE sucht, ob man es nun für sinnvoll hält oder nicht:
- encfs
- libpam-encfs

[Spindoctor]

So weit ich weiß, setzt man dazu ein Paßwort für die Platte/SSD im BIOS/UEFI. Dreimal falsch und die Platte/SSD ist permanet gesperrt. Du kannst sie nicht durch üebrschreiben mit Nullen reinitialisieren -> Elektroschrott. Eine Technik, für die es keine Möglichkeit gibt, selbst unter Verlust der Daten das Gerät wieder verwendbar zu machen, ist mir zutiefst suspekt.

Ist das echt so? Woher sind diese Informationen? Meine beiden Platten (hier und hier) setzen jedenfalls beide auf AES-256-Verschlüsselung.

Zumindest bei einer der beiden Platten ist auch OPAL 2.0 spezifiziert. Der Heise-Artikel dazu ist leider hinter einer Pay-Wall, aber im öffentlichen Teil steht bereis:

Ein Self-Encrypting Drive (SED), egal ob Festplatte oder SSD, schreibt ausschließlich verschlüsselte Daten auf seine Magnetscheiben oder in seine Chips. Die Verschlüsselung – meistens AES128 oder AES256 – lässt sich nicht abschalten. Den geheimen Schlüssel generiert die SED-Elektronik selbst.

Meines Wissens kann man mit sedutil die Verschlüsselung managen, also nicht NUR im BIOS/UEFI.

Allerdings wirkt das sedutil-Projekt in Github sehr stabil - oder eben sehr schlecht gepflegt. Außerdem verlässt man sich (auch mit AES-256), wie Du (MSfree) schon schreibst darauf, dass der Hersteller keine Hintertür oder Fehler in der Implementierung hinterlassen hat.

Vielleicht gibt es noch weitere Nachteile... jedenfalls genießt SED nicht unbedingt einen guten Ruf...

[Spindoctor]

Ich habe im Repository noch etwas gefunden, was für mich so klingt, als wäre es genau das was der TE sucht, ob man es nun für sinnvoll hält oder nicht:
- encfs
- libpam-encfs

Danke smutbert. Klingt gut. EncFS kannte ich bereits, libpam-encfs noch nicht. Leider habe ich keine halbwegs aktuelle Anleitung dafür gefunden, wie man das implementiert. Wirkt so, als hätte die Welt daran auch das Interesse verloren?
Bzw. ist es wirklich einfach zu integrieren?

Insgesamt glaub ich, haben mich die vielen kritischen Stimmen hier schon halbwegs überzeugt, dass mein ursprüngliches Vorhaben vielleicht eh nicht so sinnvoll ist.