(gelöst) cryptsetup, Passwort-Eingabe-Aufforderung

[guennid]

Sehe ich recht, dass man die ohne Eingriff in den Quellcode nicht ändern kann? Unterdrücken?

[jph]

Das Verhalten beim Booten wird über die /etc/crypttab gesteuert.

[spiralnebelverdreher]

Sehe ich recht, dass man die ohne Eingriff in den Quellcode nicht ändern kann? Unterdrücken?

Es gibt mehrere Methoden, dem Programm cryptsetup Schlüsselmaterial zu übergeben. Passworteingabe an der Tastatur ist nur eine davon. Was genau willst du den erreichen?

[guennid]

Tja, der Teufel liegt im Dateil. Ich will den Text der Eingabeaufforderung nicht sehen.
crypttab sieht nach Einsicht nicht danach aus, das zu ermöglichen.

[schwedenmann]

Hallo

Ich will den Text der Eingabeaufforderung nicht sehen.

Komisch bei mir, wenn ich mein verschlüseltes device öffne, tippe ich blind, da erscheint nichts auf dem Monitor.

mfg
schwedenmann

[spiralnebelverdreher]

Tja, der Teufel liegt im Dateil. Ich will den Text der Eingabeaufforderung nicht sehen.
crypttab sieht nach Einsicht nicht danach aus, das zu ermöglichen.

Ok, es geht dir also sinngemäß um den Text "Please enter password to unlock devive blablub" ? Da soll dann einfach nichts stehen?

[guennid]

@schwedenmann
Hier schon:

Code: Alles auswählen

Geben Sie die Passphrase für »[Pfad/zum/container]« ein:

@spiralnebelverdreher
Genau so! oder: Ich kreiere mir selbst einen.

[spiralnebelverdreher]

Ganz abgesehen davon, dass ich das eher unpraktisch fände - wir sind ja im Open Source Bereich und da soll ja jeder nach seiner eigenen Facon glücklich warden - sehe ich mindestens zwei Ansätze:

1) Quellcode ändern und Paket neu bauen
2) Umleitung der Standardausgabe im Startscriptt auf /dev/null oder sonst was, was nicht im Bildschirm erscheint.

[guennid]

Das Kommando ist:

Code: Alles auswählen

cryptsetup luksOpen /pfad/zum/container [/dev-mapper-datei]

ad 1: Will und kann ich nicht (deswegen ja: "Sehe ich recht, dass ...")

ad 2: Bis jetzt gescheitert

[jph]

Das Kommando ist:

Code: Alles auswählen

cryptsetup luksOpen /pfad/zum/container [/dev-mapper-datei]

ad 1: Will und kann ich nicht (deswegen ja: "Sehe ich recht, dass ...")

ad 2: Bis jetzt gescheitert

Ich nehme an, dass es dir um die Abfrage beim Booten geht, um ein auf einem mit dm-crypt/LUKS verschlüsselten LVM installiertes System zu starten. Da bringt (ad 2) ein Wrapper-Skript nichts, weil beim Booten cryptsetup/cryptdisks_start in der initrd und nicht in /sbin gestartet wird. Letzteres wird an der Stelle im Bootvorgang ja noch verschlüsselt sein.

Du scheinst Security by Obscurity bauen zu wollen. Dir ist bekannt, dass das ein Irrweg ist?

[TomL]

Das Verhalten beim Booten wird über die /etc/crypttab gesteuert.

Wenn man das heute noch so einrichtet.... aber brauchen tut mans seit Jessie nicht mehr. Ich würde heute immer den Weg via systemd-service-Unit wählen.

[guennid]

Ich nehme an, dass es dir um die Abfrage beim Booten geht, um ein auf einem mit dm-crypt/LUKS verschlüsselten LVM installiertes System zu starten.

Ach was, sowas Exquisites kann ich gar nicht.
Das ganze ist ja nicht so wichtig, aber ich find's halt doof, dass der eigentliche container schon beim Aufrufversuch von cryptsetup Hinz und Kunz genannt wird. Und außerdem würde ich gern ein kleines, feines Fensterchen konstruieren, in dem das Passwort abgefragt wird.

Du scheinst Security by Obscurity bauen zu wollen.

Um dazu was sagen zu können, müsst' ich wissen, was man/du darunter verstehst.

[TomL]

Ich will den Text der Eingabeaufforderung nicht sehen. crypttab sieht nach Einsicht nicht danach aus, das zu ermöglichen.

Doch, natürlich geht das... nur würde ich das nicht machen, weil Du damit einen Teil der Sicherheit zu einem Zufallsprodukt machst. Du kannst selbstverständlich das Password selber abfragen, mit einem eigenen wohlklingenden Text, und dann die Eingabe direkt via stdin an Cryptsetup übergeben. Allerdings besteht dann die Möglichkeit, dass das Password entweder in Reinschrift in der Prozessliste steht oder in Reinschrift in der User-History.

Wenn Du das trotzdem unbedingt so machen willst, gibts ne Möglichkeit, mit der zumindest der Reinschrifttext des PWDs nicht lesbar ist und das das PWD spätestens beim shutdown endgültig weg ist.

Ich würde via base64 ein verkryptetes Password erzeugen... so in dem Muster:

Code: Alles auswählen

# echo "günni is der chefhacker" | base64
Z8O8bm5pIGlzIGRlciBjaGVmaGFja2VyCg==

# echo "günni is der chefhacker" | base64 >/tmp/containerkey

# cat /tmp/containerkey
Z8O8bm5pIGlzIGRlciBjaGVmaGFja2VyCg==

Dann gehst Du hin, und importierst diesen Schlüssel (nach dem Öffnen des Containers) in das "Schlüsselfach" Deines Containers.

Code: Alles auswählen

cryptsetup luksAddKey /dev/loop0 /tmp/containerkey

Und nun kannst Du in Deinem "Open-Container"-Script ein Password mit beliebigen Text abfragen, bei dem der User "günni is der chefhacker" eingeben muss und generierst on-the-fly das Keyfile in /tmp... exakt wie oben angegeben. Danach kannst Du den Container mit Angabe des fliegend erstellten Keyfiles öffnen.

Code: Alles auswählen

cryptsetup luksOpen /dev/loop0 container --key-file /tmp/containerkey

Solange der PC an ist und tmpfs->/tmp/containerkey besteht, kann man sich das sichern... das ist das Risiko, allerdings sollte es einem Laien fast unmöglich sein, das Password in Reinschrift zu reproduzieren. Nachtrag.... mir fällt gerade ein, man kann das Keyfile auch einfach direkt nach dem LuksOpen löschen... man braucht es ja wirklich nur für den Moment des Öffnens....

[jph]

Das Verhalten beim Booten wird über die /etc/crypttab gesteuert.

Wenn man das heute noch so einrichtet.... aber brauchen tut mans seit Jessie nicht mehr. Ich würde heute immer den Weg via systemd-service-Unit wählen.

Erzähl mir bitte mehr.

[TomL]

Das Verhalten beim Booten wird über die /etc/crypttab gesteuert.

Wenn man das heute noch so einrichtet.... aber brauchen tut mans seit Jessie nicht mehr. Ich würde heute immer den Weg via systemd-service-Unit wählen.

Erzähl mir bitte mehr.

Da is nix zu erzählen.... Öffnen, mounten, umounten und schließen einfach in eine kleine systemd-service-unit eintragen, dazu ne Condition aufs Keyfile (wenn USB-Stick), die Unit passend in den Start einfügen und den Rest macht systemd. In Kombination mit UDEV funktioniert das als Reaktion auf den Stick sogar auch Hot-Plug-mäßig. Das heisst, bei mir wird die Unit sogar immer über UDEV angezogen, unterwegs mit fliegendem USB-STick, zuhause mit "persistenter" SDC. Also wirklich total easy und zuverlässig.

BTW, systemd ist hier sowas von total offtopic... *fg*... und sollte auch nicht genannt oder als Vorschlag in Erwägung gezogen werden... ... und wenns doch genannt wird, immer ein Töpfchen mit Weihwasser daneben stellen.

[spiralnebelverdreher]

Das ganze ist ja nicht so wichtig, aber ich find's halt doof, dass der eigentliche container schon beim Aufrufversuch von cryptsetup Hinz und Kunz genannt wird. Und außerdem würde ich gern ein kleines, feines Fensterchen konstruieren, in dem das Passwort abgefragt wird.

Wenn nur Hinz und Kunz deine Gegner sind, dann kannst du mit der Offenlegung des Containernamens beruhigt schlafen. LUKS Container haben einen großen Header (um das Schlüsselmaterial über viele Sektoren zu verteilen) und sind leicht zu entdecken wenn die Festplatte einem Gegner in die Hände fällt. Die Qualität liegt im Konzept (http://tomb.dyne.org/Luks_on_disk_format.pdf) des Umgangs mit Passwörtern.

Dass es schickere Fensterchen für die Eingabe geben könnte, ist sicher richtig.

Viel Spaß beim Tüfteln!

[guennid]

Nicht schlecht, Thomas, nicht schhlecht! Ich glaube, das probier ich! MEIN container is' ne einfache Datei und da find' ich's schon blöd, dass man deren Pfadnamen sehen kann. Sowas wie keyfile auf Stick und automatisch mounten und systemd-unit (könnte man eigentlich mal zum Unwort des Jahres erklären ) ist mir viel zu viel overhead. Also nochmal zur Beruhigung, es geht mir nur um eine wenig Optik, sonst nichts.

Dazu sollte ich jetzt noch wissen, wie man das Bildschirmecho einer Tastatureingabegabe unterdrückt, bzw. durch * oder sowas ersetzt. Ich finde nix (habe wohl keine geeigneten Suchbegriffe).

[spiralnebelverdreher]

MEIN container is' ne einfache Datei und da find' ich's schon blöd, dass man deren Pfadnamen sehen kann.

Soso, es soll also niemand ahnen dass du in /home/guennid/Dokumente/Finanzen/Liechtensteinbank.container irgendwelche interessanten Dokumente aufbewahrst ? Verstehe ...

Aber du hast natürlich recht, wenn der Sinn der Verschlüsselung die Privatheit ist, dann sollte man diese nicht durch die Preisgabe von Metadaten (wie Pfadnamen) unterlaufen.

[guennid]

Soso, es soll also niemand ahnen dass du in /home/guennid/Dokumente/Finanzen/Liechtensteinbank.container irgendwelche interessanten Dokumente aufbewahrst ? Verstehe ...

Erwischt! Scheiße!

[TomL]

Soso, es soll also niemand ahnen dass du in /home/guennid/Dokumente/Finanzen/Liechtensteinbank.container irgendwelche interessanten Dokumente aufbewahrst

Erwischt! Scheiße!

Güüüüünther.... .... muss ich nun Angst haben, dass mir jetzt die Steuerfahndung aujf den Fersen ist, wegen meines Beitrags hier im Thread und dem damit erfüllten Tatbestand Beihilfe zur Steuerhinterziehung? Und sollte ich deshalb jetzt besser meinen caymanbank.container umbennen...?... in was unverfängliches...?... wie "geheimekonten.volume" oder so....

Das "Erwischt!" beunruhigt mich ja nun doch....

[guennid]

Kann man das PW auch im Klartext in ein für cryptsetup lesbares keyfile schreiben?

Bevor jetzt das Geschrei wieder losgeht, bitte diese Bemerkung von Thomas bedenken:

mir fällt gerade ein, man kann das Keyfile auch einfach direkt nach dem LuksOpen löschen... man braucht es ja wirklich nur für den Moment des Öffnens...

[pangu]

Hi guenni,

schau dir mal plymouth an. Das sieht dann richtig schick aus beim Booten und vllt. wirst du damit glücklich

[guennid]

Es geht nicht ums Booten.

[TomL]

Kann man das PW auch im Klartext in ein für cryptsetup lesbares keyfile schreiben?

Ja sicher geht das... ich mache das nur.... USB-Stick mit Keyfile rein, an "fixe" Stelle mounten und von dort den Key laden.....

Code: Alles auswählen

/sbin/cryptsetup luksOpen "/dev/disk/by-uuid/8-37c7a1fd215" Crypt_HD --key-file "/var/run/.keys/CryptCredentials"

Und für meine Backupplatten, die ich rotierend antischnüffelsicher ausser Haus lagere, liegt das Keyfile ganz einfach in meinem Homedir.

[guennid]

Funktioniert hier noch nicht.

Der Plan ist: PW per dialog in eine Variable, diese in ein Keyfile (meinetwegen auch via base64). keyfile wie von dir o.a. bekanntmachen und später container via keyfile per script öffnen und mounten. Hinterher keyfile löschen.

Ich probier noch. Deine Vorgehensweise ist ein paar Nummern zu anspruchsvoll für mich.