Am Sonntag, 20. April 2008 schrieb Ralf Goos:

(...). vielen Dank für deine Antwort. Dein Tip hat geholfen, jetzt steh ich allerdings vor weiteren Problemen. Aber der Reihe nach.

Befehlsfolge um eine KryptDatei für einen User als Homverzeichnis zu öffnen (die KryptDatei muss natürlich zuvor mit YaST erzeugt werden): 1) losetup /dev/loop1 /home/KRYPTDATEI 2) cryptsetup luksOpen /dev/loop1 cr_KRYPTDATEI => jetzt wird das Passwort abgefragt 3) mount /dev/mapper/cr_KRYPTDATEI /home/MOUNTPOINT -t ext3 -o acl,user_xattr,noauto => jetzt steht das Homeverzeichnis (aus der KryptDatei) zur Verfügung

Und hier die Befehlsfolge um den Zugang zur KryptDatei vollständig wieder zu entfernen: 1) umount /dev/mapper/cr_KRYPTDATEI -d -l 2) cryptsetup luksClose cr_KRYPTDATEI 3) losetup -d /dev/loop1

Das paßt ganz zu der in http://en.opensuse.org/Encrypted_Filesystems beschriebenen Vorgehensweise, ergänzt um das Loopback-Device.

Das ganze hat aber den Haken, dass es nur als user root ausführbar ist.

Da bliebe noch sudo.

Ich wollte das Ausführen der BankingSW und die zugehörigen Daten aber nur einem einzigen User auf dem Rechner einrichten, quasi beim Login/Logout obige Befehle ausführen. Da möchte ich nicht mit sudo arbeiten und jedes mal noch das root-Kennwort eintippen.

IIRC kannst du sudo ja auch so einstellen, daß nur bestimmte Benutzer oder Gruppen für bestimmte Befehle kein Paßwort brauchen.

Deshalb habe ich jetzt (wie du auch vorgeschlagen hast) beim Anlegen des Users gleich ein verschlüsseltes HomeVerzeichnis eingerichtet. Hier arbeitet Suse wohl mit "pam", jedenfalls ist ein entsprechender Eintrag in "/etc/security/pam_mount.conf" zum mounten des verschlüsselten HomeVerzeichnis vorhanden.

Genau, dafür wird "pam_mount" genutzt. Und "cryptconfig" dient als Verwaltungs-Tool.

Das Ergebnis stellt mich aber nicht zufrieden. Da nach dem logout des Banking-users dessen verschlüsseltes HomeVerzeichnis immer noch gemountet ist, und mit "root-Berechtigung" voll zugänglich.

Hast du noch einen Rat?

Bist du dir ganz sicher, daß nach dem Logout noch das entschlüsselte Home-Verzeichnis sichtbar ist? Ich bin da auch zuerst ein wenig verwirrt gewesen, da YaST auch ein unverschlüsseltes Home-Verzeichnis mit den Standard-Dateien und -Verzeichnissen anlegt und das anfangs natürlich noch genau so aussieht wie das eigentlich verschlüsselte. Sprich, wenn du neue Dateien anlegst, siehst du die auch noch nach einem Logout? Und überprüfe die Ausgabe von "mount", ob dort tatsächlich noch ein Eintrag wie "/dev/mapper/_dev_loop0 on /home/..." vorhanden ist. Es kann aber durchaus passieren, daß irgendein Programm noch auf das Home-Verzeichnis zugreift, sodaß es nicht ge-umountet werden kann. Beagle soll einer der Kandidaten sein. Falls dem so ist, müßte ich auch selbst noch was danach googlen, denn bei mir funktioniert das (ohne beagle) wunderbar. Gruß Jan -- I am Bashir of Borg. Prepare to be... did anyone ever tell you that you have beautiful eyes? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Montag, 21. April 2008 schrieb Ralf Goos:

Am Montag, 21. April 2008 19:49:40 schrieb Jan Ritzerfeld:

...

Am Sonntag, 20. April 2008 schrieb Ralf Goos: (...). IIRC kannst du sudo ja auch so einstellen, daß nur bestimmte Benutzer oder Gruppen für bestimmte Befehle kein Paßwort brauchen.

Das würde mich interessieren, wie ich einem User meiner Wahl (der keine root-Rechte hat) dazu verhelfen kann, dass er mount/umount, cryptsetup und losetup ausführen darf.

Wenn du die pam_mount-Methode nutzt, sollte es reichen, dem Benutzer mount.crypt und umount.crypt zur Verfügung zu stellen: https://anon-web.aioe.org/daten_verschluesseln_dm-crypt.htm Unter 1. steht wie man sudo dafür konfiguriert und unter 5. wie man mount.crypt und umount.crypt benutzt.

(...).

...

Bist du dir ganz sicher, daß nach dem Logout noch das entschlüsselte Home-Verzeichnis sichtbar ist? Ich bin da auch zuerst ein wenig verwirrt gewesen, da YaST auch ein unverschlüsseltes Home-Verzeichnis mit den Standard-Dateien und -Verzeichnissen anlegt und das anfangs natürlich noch genau so aussieht wie das eigentlich verschlüsselte. Sprich, wenn du neue Dateien anlegst, siehst du die auch noch nach einem Logout? Und überprüfe die Ausgabe von "mount", ob dort tatsächlich noch ein Eintrag wie "/dev/mapper/_dev_loop0 on /home/..." vorhanden ist.

Du hast Recht, jetzt bin ich verwirrt.

Wie gesagt, war ich im ersten Augenblick auch.

In dem Homeverzeichnis sind (nach logout des BankingUsers) zwar alle Dateien vorhanden, aber von altem Datenstand (Freitag letzte Woche).

Also der Inhalt entspricht dem Stand zum Zeitpunkt des Anlegens von dem verschlüsselten Home-Verzeichnis?

Es ist auch definitiv kein loopbackdevice mehr vorhanden, sowie es keinen aktiven mount auf das verschlüsselte home-Verzeichnis mehr gibt

Das ist erst einmal das wichtigste. Sonst müßten wir pam_mount in den Debug-Modus versetzen und weiter nach den Ursachen suchen, warum das unmounten nicht erfolgreich ist.

Sieht ganz so aus, als ob ich jetzt zwei Versionen von allen Dateien habe. Je nach dem ob der owner (BankingUser) eingelogt ist, oder nicht. Das kann doch nicht gesund sein?

Gute Frage. Ich bin mir da auch nicht so sicher. Ich habe einfach das Home-Verzeichnis unverschlüsselt dort liegen lassen, welches beim Anlegen eines Benutzers erstellt wird. pam_mount ist ja nicht für alle Login-Möglichkeiten aktiviert. Ein Einloggen z. B. per su mountet das Verzeichnis nicht. Und wenn dann gar keins da ist, meckert garantiert schon die Login-Shell, daß das in /etc/passwd angegebene Home-Verzeichnis gar nicht existiert. Sprich, das unverschlüsselte Home-Verzeichnis dient als Fallback.

Kann es sein, dass diese doppelten Dateien sozusagen von der Initialbefüllung des home-Verzeichnisses noch vorhanden sind?

Wenn du mit YaST einem bestehenden Benutzer ein verschlüsseltes Home-Verzeichnis bereitstellst, dann kopiert YaST den bisherigen Inhalt in das verschlüsselte. IMHO eine sehr gute Idee. Würden die Daten verschoben, und hätte man bei der Einrichtung das Paßwort irgendwie falsch oder einfach ein falsches eingegeben oder hätte der Benutzer sein richtiges Paßwort einfach vergessen, dann wären alle Daten unwiderbringlich gelöscht.

Und kann ich die Dinger löschen?

Wenn du dir sicher bist, daß du auf das verschlüsselte Home-Verzeichnis zugreifen kannst. Und natürlich ein verschlüsseltes Backup hast, ich mache das mit dar, daß kann direkt verschlüsseln, sodaß man keine temporäre unverschlüsselte Kopie des Backups herumliegen hat. Und Löschen würde ich die Dateien mit wipe o. ä.. Sonst sind die Daten selbst ja noch auf der Platte vorhanden, man sieht sie nur nicht mehr mit den normalen Mitteln.

Oder werden die Dinger gebraucht, weil da irgendwie per loopback erkannt wird ob es Änderungen gab und wenn ja werden nur diese Änderungen in den verschlüsselten Datencontainer geschrieben?

Neee. Ich glaube nicht. Aber ich habe das unverschlüsselte Home-Verzeichnis auch nicht direkt gelöscht, sondern es erstmal verschoben und dann nachgesehen, ob noch alles da ist. Sicher ist sicher!

So was ähnliches habe ich unter dem Link http://de.wikipedia.org/wiki/EncFS den du mir geschickt hast gelesen.

Das bezog sich darauf, daß du bei einem mit EncFS verschlüsselten Verzeichnis auch an den verschlüsselten Dateien noch erkennst, wann sie das letzte Mal geändert wurden. EncFS verschlüsselt ja nur die Dateien und die Dateinamen. Die Meta-Daten wie die Verzeichnisstruktur und die ganzen Timestamps bleiben unverschlüsselt. Daher kannst du dein Backup-Programm auf die verschlüsselten Dateien loslassen und trotzdem inkrementelle und differenzielle Backups o. ä. durchführen. Sprich, beim ersten mal alles "backupen" und danach nur die Änderungen, die sich seit dem Zeitpunkt des vorherigen Backups (oder des ersten) ergeben haben. HTH Jan -- Idiot Box: The part of the envelope that tells a person where to place the stamp when they can't quite figure it out for themselves. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Dienstag, 22. April 2008 schrieb Ralf Goos:

(...). Habe das unverschlüsselte Home (mit den doppelten Daten) umbenannt und ein neues leeres home (mit gleichem Namen) erstellt, und siehe da, alles funzt tadellos, d.h. das waren tatsächlich irgend welche Überbleibsel von der Initialbefüllung. Wenn der BankingUser jetzt ausgelogged ist, ist das home leer, wenn er eingelogged ist stehen die Daten wie gewünscht zur Verfügung. Ich bin begeistert.

Eine Sache bleibt noch, bei der ich mir selbst noch nicht so sicher bin. Und zwar die Mount-Optionen mit denen das verschlüsselte Home-Verzeichnis eingebunden wird. Wenn du dir mal die Ausgabe von "mount" ansiehst, wird dir auffallen, daß dein normales /home mit "rw,acl,user_xattr" dein verschlüsseltes Abbild aber nur mit "rw" eingebunden wird. Diese Optionen kann man in /etc/security/pam_mount.conf am Ende einstellen, z. B.: volume jan crypt - /home/jan.img /home/jan loop,acl,user_xattr aes-256-cbc Was mir noch eingefallen bzw. aufgefallen ist: Das Home-Verzeichnis ist ja nun ein Abbild was als eigenständiges Dateisystem eingebunden wird. Letztlich bedeutet das aber auch, daß zwei Caches mit im Spiel sind. Erst puffert das Dateisystem des eingebundenen Abbilds und dann nochmal das eigentliche /home-Dateisystem. Bei Lesezugriffen mag das ja noch relativ egal sein, aber bei Schreibzugriffen steigt doch so die Wahrscheinlichkeit daß beim einem Absturz o. ä. Daten verloren gehen, oder? Wäre es da nicht geschickt, das Abbild mit der Option "sync" einzubinden und so das Schreib-Caching dem normalen /home-Dateisystem zu überlassen?

Vielen Dank Jan für deine Hilfe.

Keine Ursache. Gruß Jan -- Delusions are often functional. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Freitag, 25. April 2008 schrieb Ralf Goos:

Am Donnerstag, 24. April 2008 20:35:50 schrieb Jan Ritzerfeld: (...).

...

Wenn du dir mal die Ausgabe von "mount" ansiehst, wird dir auffallen, daß dein normales /home mit "rw,acl,user_xattr" dein verschlüsseltes Abbild aber nur mit "rw" eingebunden wird. Diese Optionen kann man in /etc/security/pam_mount.conf am Ende einstellen, z. B.: volume jan crypt - /home/jan.img /home/jan loop,acl,user_xattr aes-256-cbc

stimmt habe dem aber keinen tieferen Sinn beigemessen, dies bezieht sich wohl auf das Filesystem welches gemountet werden soll acl = enable POSIX Access control List user_xattr = extende User Attributes

ich gehe mal davon aus, dass ein mount nur mit dem Kennwort des verschlüsselten Datencontainers möglich ist, und hoffe dass dies nicht zu brechen ist (...).

"user_xattr" sind nicht unbedingt eine Sicherheitsmaßnahme. Z. B. benutzt beagle sie, um den Indexierungsprozeß zu beschleunigen: http://beagle-project.org/Enabling_Extended_Attributes Gruß Jan -- No action is without side effects. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

On Wed 23 Apr 2008 05:47:41 NZST +1200, Lothar Vorrath wrote:

6. Eintrag in /etc/fstab ergänzen :

/local/privat /privat ext2 noauto,user,acl,exec,user_xattr,loop=/dev/loop2,encryption=twofish256

Das geht beir mir auch, und ist für mobile Backup-Platten gut zu gebrauchen. Als $HOME taugt es aber nicht (weil der Benutzer sich erst einloggen müßte, um sein $HOME einzuhängen, damit er sich dann einloggen könnte...). Du solltest nur loop angeben und das =/dev... weglassen, dann sucht er sich selber ein freies. Wenn loop2 schon benutzt ist, wenn Du /privat einhängst, kriegst Du Ärger. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Am Donnerstag, 24. April 2008 19:50:32 schrieb Jan Ritzerfeld:

Am Dienstag, 22. April 2008 schrieb Lothar Vorrath:

...

[...] Ach ja die 4000 MB können problemlos verschlüsselt auf eine DVD gebrannt werden.

So hatte ich das zuerst auch vor, bevor ich in der openSUSE-Dokumentation gelesen habe, daß man mit YaST ein verschlüsseltes Home-Image nahezu idiotensicher erstellen kann. pam_mount sorgt dann dafür, daß es bei einem richtigen Login automatisch gemountet wird und auch dafür, daß es wieder "ungemountet" wird sobald sich der Benutzer abmeldet.

Prinzipiell solltest du dir auch mal den Artikel durchlesen, den ich Ralf empfohlen habe: https://anon-web.aioe.org/daten_verschluesseln_dm-crypt.htm Du machst dir das Leben nämlich schwieriger als nötig. :)

Als Ersatz für so eine eigenständige, verschlüsselte Partition benutze ich EncFS. Das hat ein paar Vorteile bzgl. Backups und es hat keine feste Größenbeschränkung, da es die Dateien und deren Namen einzeln verschlüsselt: http://de.wikipedia.org/wiki/EncFS

Gruß Jan -- Strike while the iron is still hot.

Hallo zusammen, für Banking ein verschlüsseltes Homeverzeichnis, wie von Jan beschrieben, kann ich nur empfehlen. Ich habe dafür einen einzigen User angelegt. Die Bankdaten stehen dadurch absolut nur dann zur Verfügung, wenn dieser Bankinguser angemeldet ist. Und mit diesem user mache ich dann auch nichts anderes. Den sicheren Zugang und das sichere (quasi vollautomatische) entfernen des verschlüsselten Datencontainers (Homeverzeichnis) besorgt dann SUSE per login/logout. Grüße Ralf -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org