ubuntuusers.de

Ich habe mir eine Test-Workstation eingerichtet, auf der ich mit verschlüsselten Benutzer-Verzeichnissen experimentieren möchte. Es sind ja im Wiki von Ubuntuusers sehr gute Anleitungen vorhanden. Ich hätte aber noch ein paar Rückfragen, bevor ich starte. Ich habe LUKS ins Auge gefasst. Mein Plan war, beim Anlegen der Test-Benutzer den Pfad zu einer alternativen home-partition anzugeben, die dann verschlüsselt ist. Ich wollte versuchen, gleichzeitig mehrere Benutzer mit verschlüsseltem Home-Verzeichnis und andere Benutzer ohne Verschlüsselung zu haben.

Was ich noch nicht ganz verstanden habe ist, ob es überhaupt möglich ist, dass mehrere verschiedene Benutzer ein verschlüsseltes Home-Verzeichnis auf der gleichen Partition haben (wobei jeder Benutzer einen anderen Schlüssel haben sollte).

Muss das Passwort, das ich eingeben muss, wenn ich den Befehl

1

cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sdb1

ausführe, identisch mit dem Benutzer-Passwort sein?

Falls ja, würde das ja nur für einen Benutzer Sinn machen und womöglich auch bedeuten, dass man das Benutzer-Passwort nicht mehr ändern kann, ohne die ganze Verschlüsselung neu zu berechnen.

In einer der Beschreibungen steht, dass man die Festplatte zunächst mit Nullen oder Zufallszahlen vollschreiben soll, wenn schon unverschlüsselte Daten auf der Platte waren, weil diese sonst mit Wiederherstellungs-Werkzeugen gelesen werden könnten.

Ich fange mit einer leeren Festplatte an. Ich frage mich aber, ob es womöglich trotzdem Sinn machen könnte, die Festplatte mit Zufallszahlen zu beschreiben.

Es handelt sich ja um ein passives System. Für den Fall, dass jemand Zugriff zur verschlüsselten Festplatte erlangt, könnte er Brute-Force Methoden anwenden, ohne von einer aktiven Instanz limitiert oder ausgebremst zu werden. Kann jemand sagen, wie groß die Datenmenge sein muss, die man in so einem Verfahren mindestens entschlüsseln muss, um zu erkennen, ob man den richten Schlüssel erraten hat?

Könnte ich den nötigen Rechenaufwand erhöhen oder es zumindest erschweren, den benötigten Rechenaufwand abzuschätzen, wenn ich die Festplatte mit Zufallszahlen fülle?

In einer der Beschreibungen steht, dass man die Festplatte zunächst mit Nullen oder Zufallszahlen vollschreiben soll, wenn schon unverschlüsselte Daten auf der Platte waren, weil diese sonst mit Wiederherstellungs-Werkzeugen gelesen werden könnten.

Ich fange mit einer leeren Festplatte an. Ich frage mich aber, ob es womöglich trotzdem Sinn machen könnte, die Festplatte mit Zufallszahlen zu beschreiben.

Wenn die wirklich leer ist und du dem vertraust, kannst du es bleiben lassen.

Bei LUKS kann man mehrere Schlüssel angeben. Dann kann aber alles mit einem der Schlüssel entschlüsselt werden, Benutzer A kann dann auch den Kram von Benutzer B entschlüsseln.

Könnte ich den nötigen Rechenaufwand erhöhen oder es zumindest erschweren, den benötigten Rechenaufwand abzuschätzen, wenn ich die Festplatte mit Zufallszahlen fülle?

Nein, das hat damit nix zu tun. Man überschreibt diese Platte nur, damit keine früher dort vorhandenen Daten vorhanden waren. Da zumindest Magnetfestplatten die Eigenschaft haben können, dass beim Schreiben nicht ganz alles überschrieben wird (mit Spezialwerkzeugen auslesbar), werden gerne mehrfach Zufallszahlen genommen, damit das etwas schwerer wird.

Wenn du den Aufwand zum Knacken erhöhen willst, nimm ein sehr langes Passwort.

Vielen Dank für die Antworten.

Ich habe jetzt das verschlüsselte Dateisystem erstellt und formatiert. Ich habe den Benutzer angelegt (so wie geplant mit dem manuell gesetztem Pfad zum Home-Verzeichnis) und die Datei /etc/security/pam_mount.conf.xml so konfiguriert wie hier beschrieben: https://wiki.ubuntuusers.de/Daten_verschl%C3%BCsseln/#pam-mount-konfigurieren

Anmeldung funktioniert, Zugriffszeiten sind hervorragend.

Folgendes ist mir aufgefallen:

Sobald ein Benutzer mit Verschlüsselung angemeldet ist, haben auch parallel angemeldete konventionelle Benutzer Zugriff auf die verschlüsselte Partition. Es ist vermutlich unvermeidbar, dass die Verschlüsselung auf Systemebene stattfindet und nicht auf Benutzerebene. Für den möglichen geplanten Anwendungsfall kann man damit leben, solange man es weiß.

Wenn sich ein Benutzer mit Verschlüsselung wieder abmeldet, bleibt die verschlüsselte Partition eingehängt und konventionelle Benutzer können darauf zugreifen, bis der Computer neu gestartet wird. Das könnte ein Dealbreaker für den von mir anvisierten Anwendungsfall sein.

Ich bin gerade Dabei in der Dokumentation von pam_mount nach einer Option zu suchen, die ich vergessen haben könnte. Komischer Weise sieht es aber so aus, als ob die verschlüsselte Partition automatisch ausgehängt werden müsste. Es könnte sein, dass es ein Fehler ist, dass dies bei mir nicht passiert.

Sobald ein Benutzer mit Verschlüsselung angemeldet ist, haben auch parallel angemeldete konventionelle Benutzer Zugriff auf die verschlüsselte Partition. Es ist vermutlich unvermeidbar, dass die Verschlüsselung auf Systemebene stattfindet und nicht auf Benutzerebene. Für den möglichen geplanten Anwendungsfall kann man damit leben, solange man es weiß.

Das kann man mit geeigneten UNIX-Rechten einstellen. Mache dich zum Besitzer und verbiete allen anderen rwx - schon können andere User da nix mehr fuhrwerken.

DJKUhpisse schrieb:

Das kann man mit geeigneten UNIX-Rechten einstellen. Mache dich zum Besitzer und verbiete allen anderen rwx - schon können andere User da nix mehr fuhrwerken.

Natürlich, danke für den Hinweis. Das habe ich auch schon. Es bedeutet aber trotzdem, dass ein Administrator der Installationen ausführen darf, auch Zugriff auf die geschützten Daten hat solange ein Benutzer mit Verschlüsselung angemeldet ist.

bugblatterbeast schrieb:

DJKUhpisse schrieb:

Das kann man mit geeigneten UNIX-Rechten einstellen. Mache dich zum Besitzer und verbiete allen anderen rwx - schon können andere User da nix mehr fuhrwerken.

Natürlich, danke für den Hinweis. Das habe ich auch schon. Es bedeutet aber trotzdem, dass ein Administrator der Installationen ausführen darf, auch Zugriff auf die geschützten Daten hat solange ein Benutzer mit Verschlüsselung angemeldet ist.

Klar, dagegen kannst du aber nix machen. root hat Vollzugriff auf das System. Wenn dich das stört, musst du ein System nutzen, wo nur du root bist.

DJKUhpisse schrieb:

Klar, dagegen kannst du aber nix machen. root hat Vollzugriff auf das System. Wenn dich das stört, musst du ein System nutzen, wo nur du root bist.

Es geht mir bei meinem aktuellen Test darum, ein bequemes System zu schaffen in dem sich die Benutzer (die sich leider nicht mit der technischen Seite des von ihnen benutzten Systems auseinander setzen wollen) soweit wie irgendwie möglich darauf verlassen können, dass ihre Daten sogar vor mir sicher sind.

bugblatterbeast schrieb:

Ich bin gerade Dabei in der Dokumentation von pam_mount nach einer Option zu suchen, die ich vergessen haben könnte. Komischer Weise sieht es aber so aus, als ob die verschlüsselte Partition automatisch ausgehängt werden müsste. Es könnte sein, dass es ein Fehler ist, dass dies bei mir nicht passiert.

Diese Meldung bekomme ich beim logout:

Mar 12 14:30:30 Test lightdm[1196]: (mount.c:68): umount messages:
Mar 12 14:30:30 Test lightdm[1196]: (mount.c:72): umount: /test: das Ziel wird gerade benutzt.
Mar 12 14:30:30 Test lightdm[1196]: (mount.c:72): umount /test failed with run_sync status 2
Mar 12 14:30:30 Test lightdm[1196]: (mount.c:72): Device _dev_sdb1 is still in use.
Mar 12 14:30:30 Test lightdm[1196]: (mount.c:882): unmount of /dev/disk/by-uuid/59298681-6da7-46be-a9d8-3bc9ec1d7bfa failed

Irgendetwas scheint noch auf das Gerät zuzugreifen, wenn pam_mount versucht es auszuhängen.

bugblatterbeast schrieb:

DJKUhpisse schrieb:

Klar, dagegen kannst du aber nix machen. root hat Vollzugriff auf das System. Wenn dich das stört, musst du ein System nutzen, wo nur du root bist.

Es geht mir bei meinem aktuellen Test darum, ein bequemes System zu schaffen in dem sich die Benutzer (die sich leider nicht mit der technischen Seite des von ihnen benutzten Systems auseinander setzen wollen) soweit wie irgendwie möglich darauf verlassen können, dass ihre Daten sogar vor mir sicher sind.

Das funktioniert prinzipbedingt nicht.

DJKUhpisse schrieb:

Das funktioniert prinzipbedingt nicht.

Daher versuche ich zu evaluieren, wie nahe man dem kommen kann.

Multi-Benutzer Workstation mit paralleler Nutzung scheint schon mal ausgeschlossen.

Ich kam mir aber schon vorstellen, dass man sicherstellen könnte, dass die Passphrase die für die Einrichtung der Verschlüsselten Partition verwendet wird, nirgendwo gespeichert bleibt und auch ein Administrator nicht ohne diese Passphrase auf die verschlüsselten Daten zugreifen kann.

bugblatterbeast schrieb:

Irgendetwas scheint noch auf das Gerät zuzugreifen, wenn pam_mount versucht es auszuhängen.

Ich habe versucht folgende Optionen <edit>in der pam_mount Konfiguration</edit> zu setzen:

Default:

1

<logout wait="0" hup="no" term="no" kill="no" />

Bearbeitet:

1

<logout wait="5" hup="no" term="yes" kill="yes" />

Die Wartezeit hat einen Einfluss auf das Erscheinen der Fehlermeldungen im log. Das generelle Problem konnte ich mit den Änderungen aber nicht lösen.

Das Attribut wait der Option logout muss in Millisekunden angegeben werden. Daher machen nur größere Werte als in meinem letzten Post auch Sinn.

Es ist aber echt traurig. Auch mit 15 Sekunden Wartezeit schlägt es fehlt. Dann aber mit einer anderen Fehlermeldung.

No vfsmount found while searching for "/test" as a container file, or as a mountpoint. (According to the intersection of cmtab (/run/cmtab) with smtabs)

Das könnte mit umount.crypt zusammenhängen.

Nach Logout (mit immer noch eingehängter Partition) funktioniert folgendes nicht:

1
2

umount.crypt /test
No vfsmount found while searching for "/test" as a container file, or as a mountpoint. (According to the intersection of cmtab (/run/cmtab) with smtabs)

Das hier führt zu dem gewünschten Zustand:

1
2

umount /test
cryptsetup close _dev_sdb1

Wenn ich dann den cryptunmount Befehl durch ein entsprechendes script ersetze, kommen zwar keine Fehlermeldungen mehr aber es ändert sich auch nichts.

/usr/local/bin/unmount_test.sh

1
2
3
4

#!/bin/bash

umount /test
cryptsetup close _dev_sdb1

/etc/security/pam_mount.conf.xml

...
<cryptumount>/usr/local/bin/unmount_test.sh</cryptumount>
...

bugblatterbeast schrieb:

DJKUhpisse schrieb:

Das funktioniert prinzipbedingt nicht.

Daher versuche ich zu evaluieren, wie nahe man dem kommen kann.

Ein Admin kann immer im Zweifel alles, das ist die Idee von einem Admin. Traut man einem Admin nicht, hat man ein Problem.

Du kannst jetzt irgendwas mit Pseudo Security erfinden/basteln, aber du wirst das Prinzip nicht ändern.

Ja, grundsätzlich will ich Euch beiden natürlich gar nicht widersprechen. Ein System kann in der Realität sowie niemals absolut sicher sein kann und wenn man bereits Administrator-Rechte hat, hat man es natürlich besonders leicht. Wenn ich von Sicherheit rede, bin ich natürlich realistisch genug um immer relative und der Situation angemessene Sicherheit zu meinen.

Es geht nicht darum irgend etwas selbst zu erfinden sondern einfach nur darum ob es möglich wäre, dass ein oder mehrere Benutzer z.B. Betriebsräte auf dem System ein verschlüsseltes Verzeichnis haben, deren Passphrase der Administrator nicht mehr zur Verfügung hat. Durch Konten mit Benutzerverzeichnissen auf einer nicht verschlüsselten Partition könnte man das System besonders bequem wartbar halten.

Selbstverständlich wäre es mit entsprechendem Aufwand und erst recht mit etwas krimineller Energie möglich, an die Daten heran zu kommen. Besonders wenn man es nicht eilig hat und man die Zeit hat das System zu manipulieren und auf die nächste Anmeldung zu warten. Man schafft aber eine Hürde, die zumindest dagegen hilft, dass der Kunde seinen unerfahrenen Aushilfs-Admin sagt, dass er mal schnell die persönlichen Daten auslesen soll.

Im Moment ist es ja sowieso nur ein Test.