staging.inyokaproject.org

Eine Bitte noch: Bin derzeit selten direkt am PC, aber es sieht für mich so aus, als ob die schöne, klare, alte Variante, die bei mir funktionierte, ersetzt wurde. Lasst das Zeug bitte drin und ergänzt sämtliche eurer "Spezialbefehle" nur. Ok, das mit dem ramfs kann durch <() ersetzt werden. Ich hätte eher die Bedingungen für die alte Variante näher beschrieben, also Sicherheitsschlüssel zuerst anlegen, wenn möglich. Könnte man optional ergänzen, aber wenn diese Fliege nun auch ohne x Pipes erschlagen wurde, meinetwegen.

Benno-007 schrieb:

… schöne, klare, alte Variante, die bei mir funktionierte, …

Offen gestanden, ist mir nicht klar, was Du meinst: Dass Du ohne Erklärung eine kryptische Pipe-Befehlskette benutzt, um die Passphrase temporär zu speichern, und zwar genau im Widerspruch zum einzigen in der Einführung benannten Vorteil:

Der Vorteil ist, dass kein Passwort im Klartext auf der Festplatte gespeichert werden muss.

ist in meinen Augen nicht schön und alles andere als klar. Wenn man so etwas macht (im Wiki!) dann sollte man zumindest ein paar Worte dazu verlieren, dass das Passwort nun zwar doch gespeichert wird, aber nur temporär und in ein einer RAM-Disk, so dass tatsächlich keine Reste auf der Festplatte verbleiben. Aus den im Header verlinkten Wissensblöcken kann man nicht voraussetzen, dass ein Leser das Vorgehen auch nur im Ansatz nachvollziehen kann. Doch darum geht es m.E. im Wiki: Nicht wild irgendwelche Howto-Befehle abschreiben, sondern verstehen, was dahintersteckt.

Dass das ganze (bei Dir) funktioniert hat, stellt niemand in Frage. Im Moment hat man sehr gut die Möglichkeit, beide Versionen miteinander zu vergleichen, indem man Baustelle und Artikel in Tabs nebeneinander aufruft. Und so lang ist der Artikel nicht, zum Vergleichen und Prüfen benötigt man sicher keine halbe Stunde.

Solltest Du konkrete Hinweise haben, dann nehme ich die gern entgegen.

ramfs war nicht von mir geschrieben, erfüllte aber trotz Verbesserungsmöglichkeiten seinen Zweck - deine Variante auch, als ich vorhin den diff kommentierte.

Bei dem ramfs ist der Key ja im RAM und nicht auf Festplatte, aber trotzdem ist das so unglaublich kompliziert... (und wer benutzt überhaupt ramfs seit es tmpfs gibt). Die Syntax für den anderen Befehl mag ungewöhnlich aussehen, ist aber eigentlich nicht schwer.

Was mir noch auffällt, du hast "Partition" zu "Beginn der Partition" gemacht, was in dem Satz aber keinen Sinn zu machen scheint, die (alten unverschlüsselten) Daten sind doch auf der ganzen Partition verteilt nicht nur am Beginn derselben. Die Frage "Überschreiben oder nicht" ist aber wohl eher ein Thema für den Hauptartikel...

lionlizard schrieb:

crazy-biscuit schrieb:

Das muss man generell nicht mehr. Siehe: …

Ich weiß nicht, was Du damit sagen willst? Natürlich kann man eine weitere Passphrase hinzufügen. Es geht doch aber darum, einen Schlüssel zu benutzen, der in keiner Datei gespeichert ist, und somit nicht in Gefahr gerät, von jemand anderem entwendet zu werden.

Hast du genau geschaut was dort in der Ausgabe steht? Ich kann eine Datei als Keyfile angeben. Damit steht nirgends ein Passphrase in Form eines Passworts im Klartext, der Angreifer müsste also die Datei entwenden. Dazu müsste also bereits das System komprimittiert sein. In diesem Fall macht es m.E.n. keinen Unterschied, ob ich das Passphrase aus dem RAM sniffe oder die Datei kopiere. Selbstverständlich sollte die übrigens nur für root lesbar sein.

Ich will mich an dieser Stelle absolut nicht darüber streiten, welches Verfahren besser ist. Ich möchte es nur verstehen. Wenn ich zur Zeit des Logins einen weiteren Datenträger mounten will ist das eine valide Möglichkeit eine Schlüsselableitung zu verwenden. Zumindest unter Ubuntu. Die andere Variante wäre nur eine Alternative. Es besteht natürlich keine Notwendigkeit diese anzubringen.

Lediglich im von mir genannten Szenario, dass ich einen Wechseldatenträger zu einem beliebigen Zeitpunkt anschließe, mounte und automatisch entschlüssel brauche ich diese Variante. Ich war am Überlegen das in einen extra Artikel auszulagern, weil es verschiedene Aspekte miteinander vereint, die der geneigte Anwender sonst auf 5 Wikiseiten und weiteren Quellen manuell suchen müsste.

frostschutz schrieb:

Die Syntax für den anderen Befehl mag ungewöhnlich aussehen, ist aber eigentlich nicht schwer.

Ich meine auch nicht, dass das schwer ist. Es war mir aber komplett unbekannt und ist auch nicht wirklich selbsterklärend, wenn man ohne Anleitung oder Erklärung darauf stößt. Und an meine Medikamente muss ich mich auch erst gewöhnen.

frostschutz schrieb:

Was mir noch auffällt, du hast "Partition" zu "Beginn der Partition" gemacht ...

Nach meiner Beobachtung überschreibt der Befehl

cryptsetup luksFormat <Gerät> 

doch die gesamte Partition - bis auf einen kleinen Bereich am Anfang - mit Zufallszahlen. Daher steht im LUKS-Hauptartikel auch die Anweisung, die ersten 8 Mb mittels dd überschrieben.

Habe ich hier etwas übersehen/falsch verstanden?

Im übrigen klingt die Ursprüngliche Formulierung fast so, als seien ohne das Überschreiben Daten trotz Verschlüsselung noch auszulesen

Hinweis:

Es ist aus Sicherheitsgründen empfehlenswert die Partition ein mal mit Zufallszahlen zu überschreiben, vor allen Dingen, wenn auf dieser vorher unverschlüsselte Daten gespeichert waren. ^[5] Ansonsten sind unter Umständen viele Dateien nach dem Verschlüsseln noch auslesbar.

crazy-biscuit schrieb:

Ich kann eine Datei als Keyfile angeben. Damit steht nirgends ein Passphrase in Form eines Passworts im Klartext, der Angreifer müsste also die Datei entwenden.

Eine Schlüsseldatei (Keyfile) enthält die Passphrase im Klartext und wird von cryptsetup auch genau so behandelt. Einen Unterschied zu einem eingetippten Passwort sehe ich darin, dass die Schlüsseldatei auch Zeichen enthalten kann, die über die Tastatur praktisch nicht einzugeben sind.

Dazu müsste also bereits das System komprimittiert sein. …

Nicht zwangsläufig. Die größte Schwachstelle im System ist und bleibt der Mensch. Wenn man mit Schlüsseldateien hantiert, besteht immer die Gefahr, dass eine Kopie versehentlich nicht gelöscht wird. Man gibt beispielsweise eine Schlüsseldatei an einen Mitbewohner weiter, damit dieser eine verschlüsselte Partition auf dem Dateiserver öffnen kann. Bei dem Kopiervorgang verbleibt eine Kopie versehentlich in einem tempörären Ordner oder ein USB-Stick wird nicht ordnungsgemäß gelöscht usw. Nur wenn keine Schlüsseldatei existiert, muss man sie und ihre Kopien nicht überwachen. Der abgeleitete Schlüssel kann nur ausgelesen werden, wenn das Ursprungsgerät aktiviert wurde. Ansonsten existiert keine Kopie davon, es wird keine Kopie erstellt und es wird auch keine benötigt.

… ich einen Wechseldatenträger zu einem beliebigen Zeitpunkt anschließe, mounte und automatisch entschlüssel brauche ich diese Variante. Ich war am Überlegen das in einen extra Artikel auszulagern, weil es verschiedene Aspekte miteinander vereint, die der geneigte Anwender sonst auf 5 Wikiseiten und weiteren Quellen manuell suchen müsste.

Gegen die Idee habe ich nichts einzuwenden. Wobei die Frage, woher man den Schlüssel bezieht, eher zweitrangig ist und auch davon abhängt, an wie vielen Rechnern der Stick automatisch eingebunden werden soll. Aber gerade, wenn man einen (oder gar mehrere) Datenträger auf verschiedenen Rechnern automatisch einbinden lassen will, scheint die Nutzung eines abgeleiteten Schlüssels durchaus bedenkenswert, wenn man nicht mehr als 8 Rechner in das Szenario einbezieht. Statt einen Schlüssel von einem Rechner zum nächsten zu kopieren erzeugt man einfach jeweils einen weiteren Keyslot für den abgeleiteten Schlüssel des zusätzlichen Systems. Wobei, einen Keyslot sollte man freihalten/nutzen für ein eintippbares Passwort, um den Container im Notfall auch woanders öffnen zu können und um die anderen Keyslots zu belegen, da man das ja authentifizieren muss.

lionlizard schrieb:

Nach meiner Beobachtung überschreibt der Befehl

cryptsetup luksFormat <Gerät> 

doch die gesamte Partition

cryptsetup luksFormat schreibt nur den LUKS-Header, sonst nichts. Das sind 2MB am Plattenanfang (und davon tatsächlich geschrieben werden etwas mehr als ~128KiB, soviel belegt eine Passphrase).

Würde ja sonst Stunden dauern.

frostschutz schrieb:

cryptsetup luksFormat schreibt nur den LUKS-Header, sonst nichts. Das sind 2MB am Plattenanfang …

Habe das korrigiert. Gut, dass wir mal drüber gesprochen haben. 😉

Hallo,

keine weiteren Rückmeldung, Artikel ist wieder im Wiki. Danke für die Überarbeitung.

Gruß, noisefloor

Hallo,

für's Protokoll: letzte Änderungen von rudyr zurück gesetzt, weil alleine das chmod 777 falsch ist. Gesetzt den Fall, dass man wirklich Rechte ändern müsste, dann wäre chmod 666 ausreichend.

Gruß, noisefloor

noisefloor schrieb:

weil alleine das chmod 777 falsch ist

chmod 777 ist allermeistens falsch 😉 (wird aber aus reiner Verzweiflung benutzt)

Gesetzt den Fall, dass man wirklich Rechte ändern müsste, dann wäre chmod 666 ausreichend.

In dem Kontext noch falscher... Verzeichnisse brauchen +x / 1, mit chmod 666 funktioniert da nicht mal mehr cd...

Gemeint war vielleicht chown $USER:$USER ... und sowas ähnliches hatte rudyr ja auch zuerst dort stehen gehabt nur dann nochmal geändert...

Solange man den PC alleine benutzt und es nur einen User gibt, ist das chown in jedem Fall richtig. Zugriff für mehrere / beliebige User gleichzeitig ist dann nochmal ein Thema für sich.

Insofern wäre an dieser Stelle bestenfalls ein Hinweis auf Rechte angemessen, aber m.E. unnötig, da ein komplett anderes Thema.

Kommt drauf an! Ich kann die Referenz auf Rechte tatsächlich verstehen! On nun exakt an dieser Stelle sei dahingestellt, aber mein mit LUKS verschlüsselter USB Stick bzw. eine externe Festplatte hatte genau das Selbe Problem.

Wenn ein Laufwerk in ein Verzeichnis von root eingehängt wird, dann muss ich mich mit den Rechten befassen, wenn dort jemand anderes drauf schreiben können soll - egal, ob es mit LUKS verschlüsselt wurde oder nicht. Es handelt sich also nicht um ein LUKS-spezifisches Problem.

Das stimmt. Da stellt sich nur die Frage, wieso Dateimanager LUKS-Container automatisch immer dort mounten per default. Ein USB Stick oder eine externe Festplatte könnte genau so gut in einem Bereich mit Nutzerrechten gemountet werden....