debianforum.de

Verfasst: **08.07.2020 14:06:59**

Hallo!

Als ich vor einigen Jahren das letzte Mal ein System aufgesetzt habe, war die Linux-Welt noch einfach: um persönliche Daten zu schützen, verwendete man ecryptfs und konfigurierte es so, dass das Home-Verzeichnis beim Login eingebunden und entschlüsselt wird.

Nun bin ich dabei meinen neuen PC einzurichten und merke, wie schwierig alles geworden ist. ecryptfs hat offenbar den Kampf gegen Security-Bugs verloren und hinterlässt eine große Lücke. Ich habe das Gefühl vor lauter schlechten Optionen zu stehen:

Scheinbar(?) setzt die Linux-Welt nun auf dm-crypt, also bin ich der Empfehlung des Debian-Installers gefolgt und habe die Partitionierung mit verschlüsseltem LVM eingerichtet. Das hat für mich zwei Nachteile:

ich muss beim Systemstart zwei komplexe Passwörter mit 100+bit Entropie eingeben
ich muss das Verschlüsselungs-Passwort an alle User*innen meines Desktop-PCs weitergeben. Und es ist unwahrscheinlich, dass die Akzeptanz eines so langen Passworts bei allen Familienagehörigen gegeben ist.

Meine Anforderungen wären eigentlich ähnlich wie das, was ecrypts gemacht hat: Verschlüsselung persönlicher Daten - idealer Weise pro User. Und die und bequemes Handling mit nur einem Passwort (beim Login).

Kann das derzeit ganz, oder zumindest Teile davon, erreicht werden? Vielleicht wenigstens der Login mit nur einem Passwort?

Reicht es, wenn ich nur die Home- und Swap-Partition verschlüssle?

Danke schon jetzt!

Verfasst: **08.07.2020 14:46:29**

Spindoctor hat geschrieben:
08.07.2020 14:06:59
Reicht es, wenn ich nur die Home- und Swap-Partition verschlüssle?

Wem soll es denn genügen?

Klar kannst du die Verschlüsselung auf eine Partition begrenzen, die nur du verwendest. Du musst dir nur über mögliche Auswirkungen im Klaren sein.

1. man sieht an den Programmen in /usr/, was du so verwendest, möglicherweise auch mit Spuren in /var. Das kann, muss aber nicht unangenehm sein.
2. Du musst vor dem eigentlich Login dein home mounten oder musst deine Verschlüsselung nochmal auf einen weiteren Unterordner begrenzen - das sorgt dann aber für weitere Komplexität mit den dotfiles (Browserprofil usw.).
3. Du solltest dafür sorgen, dass /tmp/ den reboot nicht überlebt (kann sein, dass das schon standardmäßig so ist...)

Technisch ist das kein Problem - nur hast du dann mehr Aufwand.

Verfasst: **08.07.2020 14:54:40**

Spindoctor hat geschrieben:
08.07.2020 14:06:59
Reicht es, wenn ich nur die Home- und Swap-Partition verschlüssle?

Leider komme ich mit der Problembeschreibung auch nicht so recht klar.

Soll die Homepartion einmalig für alle User verschlüsselt sein, für alle User mit einem gemeinsamen PWD?
Soll jedes Homedir eines jeden User mit exklusivem individuellen Password verschlüsselt sein?
Soll die Verschlüsselung vor Missbrauch bei physischen Zugriff (Diebstahl, Einbruch, etc.) schützen?
Soll die Verschlüsselung die jeweiligen persönlichen User-Homedirs vor den anderen Usern schützen?

Verfasst: **08.07.2020 15:24:23**

Spindoctor hat geschrieben:
08.07.2020 14:06:59
Reicht es, wenn ich nur die Home- und Swap-Partition verschlüssle?

Datenbanken liegen in /var
Druckaufträge liegen in /var
Logfiles liegen in /var
Anwendungen schreiben nach /var
Anwendungen schreiben nach /tmp
Daten von root liegen in /root .. evtl auch seine Notizen womit man die Platte entschlüsselt ... ups.

Die Liste ist nicht abschließend, einfach mal die Verzeichnisse selbst durchgehen und drüber nachdenken, wozu die dort liegenden Daten gebraucht werden.
Nen Blick in den FHS kann auch hilfreich sein https://www.debian.org/doc/packaging-ma ... s-3.0.html

Verfasst: **08.07.2020 15:57:03**

Vielen Dank für Eure Antworten!

Offenbar habe ich meine Frage etwas unpräzise gestellt, ich versuche es daher nochmals:

Es ist völlig klar, dass man ein ganz (oder zumindest fast ganz) sicheres System nur bekommt, wenn man es auch vollständig verschlüsselt. Sogar ohne die von Euch angesprochenen Datenfragmente, die in /var und /tmp geschrieben werden, könnte in einem nicht vollständig verschlüsseltem System ein Angreifer meinen Browser gegen einen komprimitierten Browser austauschen und warten, bis ich die Zugangsdaten zu meinem Web-Banking eintrage. Gegen solche Szenarien hilft - wenn überhaupt irgendwas - dann wohl nur eine vollständige System-Verschlüsselung.

Aber:
In meinem Fall geht es um einen normalen Heim-Desktop-Rechner, daher scheint es mir akzeptabel, auf etwas Sicherheit zu verzichten, wenn ich dafür etwas mehr Komfort bekomme. Das heißt, ich würde es in Kauf nehmen, dass tatsächlich nur die Daten in meinem Home-Verzeichnis (und im Swap, wo die Daten ja allenfalls zwischengespeichert werden, etwa wenn ich Suspend to Disk mache) verschlüsselt sind.
Im Gegenzug will ich dafür nur beim Login ein Passwort eingeben und nicht schon beim Booten.

Im Idealfall sind meine Daten auch nur mit meinem eigenen Passwort entschlüsselbar - wenn also andere User auf meinem PC unsichere Passwörter verwenden, dann soll das nicht dazu führen, dass mein Home Folder damit ausgelesen werden kann. Nach meinen Informationen, ist diese Anforderung aber seit dem Ende von ecryptfs nicht mehr realisierbar:

Um Benutzer gegeneinander abzuschirmen gibt es zum aktuellen Zeitpunkt keine sichere Lösung für Linux.

Quelle: curius.de

Ist wenigstens die erste Anforderung (Verschlüsselung von Home und Swap mit nur einem Passwort beim Login) umsetzbar?

Verfasst: **08.07.2020 16:17:24**

Spindoctor hat geschrieben:
08.07.2020 15:57:03
Gegen solche Szenarien hilft - wenn überhaupt irgendwas - dann wohl nur eine vollständige System-Verschlüsselung.

Ein vollständig verschlüsseltes System hilft nur solange, wie der Rechner ausgeschaltet ist. Ein Angreifer kann dann zwar die Platte ausbauen und in einem anderen System auslesen, aber wegen der Verschlüsselung bekommt er halt nichts sinnvolles zu sehen. Wenn das System gebootet ist, ist auch die Platte entschlüsselt, Wer ein laufendes System angreift, hat mit oder ohre Verschlüsslung Zugriff auf alles.

Verschlüsselte Home-Verzeichnisse werden aber erst entschlüsselt wenn derjenige sich anmeldet und sind dann auf diesen Benutzer beschränkt. Selbt Root kann da nur den verschlüsselten Inhalt sehen.

Poettering ist da doch gerade aktiv, verschlüsselte Homes in systemd einzubauen. Aber das dauert wohl noch ein wenig, bis das fertig ist.

Verfasst: **08.07.2020 19:51:43**

Spindoctor hat geschrieben:
08.07.2020 15:57:03

Um Benutzer gegeneinander abzuschirmen gibt es zum aktuellen Zeitpunkt keine sichere Lösung für Linux.
Quelle: curius.de

Ist wenigstens die erste Anforderung (Verschlüsselung von Home und Swap mit nur einem Passwort beim Login) umsetzbar?

Bei Linux gibt es für alles eine Lösung... Du könntest zB eine verschlüsselte Partition erzeugen, die du nach /home/dein_user mountest. Oder eine verschlüsselte Image-Datei, die du nach /home/dein_user mountest. Lukscrypt bzw cryptsetup kann sehr viel. Also dass es für Linux nix gibt, stimmt nicht.

Verfasst: **08.07.2020 20:07:51**

debianoli hat geschrieben:
08.07.2020 19:51:43
... verschlüsselte Partition ... Oder eine verschlüsselte Image-Datei

Partitionen und Imagedateien sind halt sehr unflexibel. Wenn du 10 Benutzer auf einer 1TB-Platte hast, bekommt dann jeder 100GB? Und wenn 9 von den 10 nur 3GB brauchen, hast du 873GB verschenkt. Der 10. der 110GB braucht, läuft gegen die Partitionswand.

Individuelle Verzeichnisverschlüsselung hätte da schon seinen Reiz.

Verfasst: **08.07.2020 20:39:43**

MSfree hat geschrieben:
08.07.2020 20:07:51
Der 10. der 110GB braucht, läuft gegen die Partitionswand.

Ich persönlich habe ja große Zweifel daran, dass jemand schnell mal eben mehr als 10 GB persönliche Daten ansammeln kann... also solcherart persönliche Daten, die man selber auf irgendeine Weise durch persönliches Tun geschaffen hat und die auch tatsächlich nur einen persönlichen Zugriff erlauben sollen. Das was sich meistens als Speicherfresser aufbläht, sind doch Unmengen von Multimedia-Dateien, und bei denen sehe ich keine zwingende Notwendigkeit, warum die nicht auf einem allgemein für alle User zugänglichen Laufwerk abgelegt sind - was durchaus auch verschlüsselt sein kann.

Meine Lösung wäre eine unverschlüsselte Partition für die Homedirs ... mit je User einem 10-GB-LUKS-Container und persönlichem Password. Bei Login eines Users wird der Container via PAM geöffnet und nach ~ gemountet. Und dann noch eine sehr große verschlüsselte Partition mit gemeinsamen Password für alle, wo die User in pseudo-persönlichen Dirs ihr nicht-so-geheimnisvolles Mega-Datengrab anlegen können. Dieses große Dir würde ich nur mit Linux-Rechten pro User schützen, die Partition selber mit LUKS.

Verfasst: **08.07.2020 21:11:50**

Ich würde folgende Ansätze fahren:
- ZFS mit Verschlüsselung verwenden
- Das System vollständig verschlüsseln
- automatische Entschlüsselung via TPM (hier gibt‘s nen Thread dazu)
- Im ZFS je User-Home als eigenes ZFS mit individuellem Schlüssel, laden der User-Home-Schlüssel und mounten beim Login des Users

Verfasst: **08.07.2020 23:48:22**

Ich denke, was ich anstreben werde ist ein komplett verschlüsseltes System, das aber nicht (nur) mit Passwort verschlüsselt ist, sondern auch mit einem USB-Key (so wie hier oder hier).

Und davon abgesehen werde ich wohl der Einschätzung von TomL folgen bzw. noch etwas "bequemer" sein: Home-Verzeichnisse grundsätzlich unverschlüsselt, wer was verschlüsseln will, kann das mit EncFS, gocryptfs oder mit einem anderen entsprechenden Tool machen.

Wäre natürlich schön, wenn es irgendwann wieder eine bequeme Lösung wie seinerzeit ecryptfs geben würde...

Vielleicht wirds ja was mit der von MSfree angekündigten systemd-Lösung...

By the way - weil wir gerade von Verschlüsselung reden: Meine neuen SSDs unterstützen beide auch Hardware-Verschlüsselung. Kann man das in Linux irgendwie sinnvoll einsetzen?

Nochmals vielen Dank für Eure "Anteilnahme"

Verfasst: **09.07.2020 10:35:34**

ecryptfs hat offenbar den Kampf gegen Security-Bugs verloren und hinterlässt eine große Lücke.

Ich war schon immer der Meinung hat ecryptfs vieles versprochen was es nie halten konnte. Offensichtlich ist jetzt (IMHO zurecht) daran gestorben. Und so leid es mir tut: Da wird vermutlich auch nie irgend was in die Lücke springen, die ecryptfs nie füllen konnte.
Das ganze Sicherheitskonzept von Linux beruht darauf, dass in der Mitte der Kernel sitzt der Resourcen auf Nutzer verteilt, Interaktionen beurteilt und so die Nutzer vor sich gegenseitig schützt. Drum herum hat sich ein bunch von "Services" etabliert, die Dienste bereitstellen für diese Ressourcen bekommen und für die sie dann verantwortlich sind und sich eben ausreichend vom Kernel schützen lassen. Das nennt sich dann Betriebssystem.
In die andere Richtung war das Design mäßig nie vorgesehen. Du hast deinem Betriebsystem und den zu vertrauen. Und das hat alle Ressourcen.
Beispiel: Du druckst: Der Kernel gibt dem cups die Rechte auf den drucker zuzugreifen. Du gibst dem CUPS die Credentials und dem lp die Datei, die dein Drucker haben will. Und natürlich speichert der die in seinem Home Directory /var/spool/lpd. Und so gibt es tausende Loopholes. Am schönsten ist der eCryptfs-Key der auf der SWAP landet.
Sowas zu ermöglichen müsste einen grundsätzlichen Umbau am Linux vor sich ziehen. Das sehe ich nicht kommen. Im Serverbereich gibt es Software die so konzipiert ist, dass man dem Gegenüber eben nicht vertraut. Unmöglich ist das nicht. Linux wirst du nicht so schnell da hin bekommen.
Das schönste ist dann die Dateinamensverschlüsselung ohne die Metadaten weg zu radieren. (Weil nütztlich) Auch das: Dateisystemverschlüsslung hat Sidechannels des Todes. Tut dann bitte nicht so als ob ihr Metadaten "ein bisschen" was versteckt. Solche Systeme werden nie eine anständige Sicherheit bieten können.
Es hat der IT massiv gut getan als es noch sicher und unsicher gab. Software wird immer mächtiger und kann von jedem Volltrottel eingesetzt werden. Ein bisschen sicher ist um den Nutzer zu beruhigen und führt aber nur zu einer etwas größeren Professionalisierung bei Angreifern ohne ernsthaft irgend was zu verhindern. Und am Ende läuft das darauf raus dass die Leute meinen ich habe doch 20 ein bisschen sicher Maßnahmen gemacht und dem Schrei nach der Polizei und mehr nutzloser Überwachung und nutzloser Einschränkungen weil da ja auch so Professionelle "APT-Hacker" unterwegs sind.
Wenn du die Daten eh verlieren können willst lass es weg. Wenn nicht dann setzt ne vernünftige Lösung ein.

Verfasst: **09.07.2020 10:53:14**

Wie verschluesseln andere Desktop distros ihr /home/?

Verfasst: **09.07.2020 13:36:27**

Wie verschluesseln andere Desktop distros ihr /home/?

Das klingt jetzt Böse: Aber "seriöse" Distros bieten das nicht an. Es funktioniert nicht.
Entweder man nimmt /var, /etc, /tmp und swap (und damit läufts nicht als User) mit oder man lässt es sein.

Verfasst: **09.07.2020 13:48:03**

wanne hat geschrieben:
09.07.2020 13:36:27

Wie verschluesseln andere Desktop distros ihr /home/?
Das klingt jetzt Böse: Aber "seriöse" Distros bieten das nicht an. Es funktioniert nicht.
Entweder man nimmt /var, /etc, /tmp und swap (und damit läufts nicht als User) mit oder man lässt es sein.

Kommt das nicht aufs Angriffsszenario an?
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.

Verfasst: **09.07.2020 15:24:28**

Lord_Carlos hat geschrieben:
09.07.2020 13:48:03
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.

Verfasst: **09.07.2020 16:50:35**

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.

Verfasst: **09.07.2020 17:39:27**

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?

Verfasst: **09.07.2020 17:59:48**

fischic hat geschrieben:
09.07.2020 17:39:27
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.

Verfasst: **09.07.2020 18:22:26**

Lord_Carlos hat geschrieben:
09.07.2020 17:59:48
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.

Verfasst: **09.07.2020 18:25:36**

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

Verfasst: **09.07.2020 18:45:34**

Lord_Carlos hat geschrieben:
09.07.2020 18:25:36
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.

Verfasst: **09.07.2020 19:15:44**

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?

Verfasst: **09.07.2020 19:22:19**

fischic hat geschrieben:
09.07.2020 19:15:44
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.

Verfasst: **09.07.2020 19:34:23**

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.

debianforum.de

Aktueller Status von Daten-Verschlüsselung

Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung

Re: Aktueller Status von Daten-Verschlüsselung