staging.inyokaproject.org

Ja, aber gibt es da irgend eine Dokumentation zu. Was ist wenn das Passwort des root-Devices geändert wird? Verschlüsselt es mit dem selben internen Key wie das root-Device oder mit dem echten Passwort?

Außerdem müssen die Partitionen dann ja auch so erstellt werden, was wieder ein wenig über die LUKS-Doku hinausgeht imho. Scheint ja auch ein Debian-Script zu sein, zumindest ist nichts in der Manpage dokumentiert. Das ist wieder eher was für die Schritt-für-Schritt-Howtos.

Gruß, unggnu

unggnu schrieb:

Ja, aber gibt es da irgend eine Dokumentation zu.

Es gibt das Skript.

Was ist wenn das Passwort des root-Devices geändert wird? Verschlüsselt es mit dem selben internen Key wie das root-Device oder mit dem echten Passwort?

Mit dem internen Key als "Keyfile" für die Partition.

unggnu schrieb:

Außerdem müssen die Partitionen dann ja auch so erstellt werden, was wieder ein wenig über die LUKS-Doku hinausgeht imho.

Nein. Es funktioniert genauso wie ein Keyfile, nur ohne dessen Nachteile - und erzwingt die verschlüsselte Speicherung. Keyfiles zur automatischen Einbindung sind im Wiki weder nötig noch ratsam.

unggnu schrieb:

Scheint ja auch ein Debian-Script zu sein, zumindest ist nichts in der Manpage dokumentiert. Das ist wieder eher was für die Schritt-für-Schritt-Howtos.

Wieso? Es ist ein Teil von cryptsetup unter Ubuntu.

Ich habe gerade versucht das decrypt-derived-Script in den LUKS-Artikel zu integrieren, aber mir die Zähne ausgebissen (es müsste unter erstellen, öffnen und crypttab). Das ist einfach zu komplex/umständlich. Ich würde dafür einen extra, Unterartikel von LUKS vorschlagen. So etwas wie LUKS/Decrypted-Derived-Script oder dergleichen.

Was meint Ihr?

Gruß, unggnu

Ich habe das Schweigen mal als Zustimmung aufgefasst und die Seite zu Decrypted-Derived-Script erstellt. Die kannn später unter LUKS als empfohlene Alternative zur Schlüsseldatei eingetragen werden.

Diese Anleitung setzt die Durcharbeitung von LUKS voraus und geht deshalb nur auf das Nötigste ein.

Das hinzufügen des abgeleiteten Schlüssels ist unsauber. Hat jemand eine Idee, wie man das eleganter lösen kann?

Gruß, unggnu

Hallo,

Unterartikel ist ok.

unggnu schrieb:

Diese Anleitung setzt die Durcharbeitung von LUKS voraus und geht deshalb nur auf das Nötigste ein.

Du solltest LUKS im Wissensblock hinzufügen.

Gruß pippovic

pippovic schrieb:

Du solltest LUKS im Wissensblock hinzufügen.

Das ist der erste Punkt im Wissensblock oder ist das nicht der "Diese Anleitung setzt die Kenntnis folgender Seiten voraus"-Abschnitt?

Gruß, unggnu

Upps, übersehen. 😳

Dann bitte die Keyfiles auch entsprechend auslagern - mit demselben Warnhinweis, ergänzt um Dateisystembeschädigungen.

Ne, ne, immer nur Arbeit am auftischen 😀 .

Baustelle/LUKS/Verwendung von Schlüsseldateien

Ich hoffe aber, dass die jetzt auch schnell aus der Baustelle verschoben werden, damit die unter Luks verlinkt werden können. Ich würde dann den "Start ohne Passwortabfrage" ein wenig aufräumen und mal schauen wie man das regelt.

Es nervt ein wenig, dass das die Prüfung oder auch Nichtprüfung ☺ (wie z.B. Baustelle/System verschlüsseln/Installation ) immer so lange dauert.

Gruß, unggnu

unggnu schrieb:

Es nervt ein wenig, dass das die Prüfung oder auch Nichtprüfung ☺ (wie z.B. Baustelle/System verschlüsseln/Installation ) immer so lange dauert.

Naja... die Artikel liegen einige Tage nach Fertigstellung in der Baustelle zur Begutachtung - und gestern hast Du ja noch dran gewerkelt. 😉

Wenn Du nun fertig bist - bitte sagen oder den 'Artikel in Arbeit' Kasten entfernen.

Ja, ab und an findet man noch eine Optimierung, aber normalerweise sind die schon in der ersten Fassung vollständig und sollten korrekt sein. Geändert wird in Zukunft sicherlich auch noch was, aber dazu gibt es ja die Wiki.

Also von meiner Warte her kannst Du den und die anderen beiden auch verschieben. Die LUKS-Unterartikel können natürlich noch einmal geprüft werden.

Gruß, unggnu

So, ich habe den Artikel überarbeitet. Die beiden Unterartikel sind verlinkt, auf die Nautilus-Mount-Funktion wird deutlicher hingewiesen und auch das überschreiben der Partition mit Zufallsdaten wird nahegelegt. Wenn der Text Ok ist, würde ich den auch in den Unterartikeln jeweils unter dem Erstellen-Punkt einfügen.

Gruß, unggnu

Schaut schon besser aus, danke.

Also ich habe mir jetzt doch vorgenommen einen Home verschlüsseln-Artikel zu erstellen. Das macht mehr Sinn als pam-mount alleine, da in dem auch auf die Verlagerung von tmp in den Arbeitsspeicher, Deinstallation von mlocate und die Deaktivierung/bzw. Verschlüsselung der Swap eingegangen würde. Außerdem sollte home generell verschlüsselt werden, wenn andere verschlüsselte Container eingebunden werden. Den Rest könnte man sich da ja von ableiten. Ich würde wohl auch aus Geschwindigkeitsgründen AES-128 einsetzen natürlich mit den entsprechendem Hinweis.

Wenn das Ok ist, würde ich den wohl heute fertig machen, wenn das natürlich nicht erwünscht ist, würde ich erst gar nicht anfangen. Unterstützt wird nur >=Hardy um den pam-mount-Kram einfach zu halten.

Gruß, unggnu

Darfst Du gerne machen - und auch gerne 256 Bit nehmen. 😉

Ein verschlüsseltes SWAP erfordert dann eine Passworteingabe zur Boot-Zeit, oder?

Und mlocate kann man doch eigentlich auch so konfigurieren dass es nicht in TMP und HOME arbeitet, oder?