Anzeige:
Ergebnis 1 bis 1 von 1

Thema: boot.cryptmap - ein Bootskript zum mappen verschlüsselter Partitionen/Container-Files

  1. #1
    Registrierter Benutzer
    Registriert seit
    Oct 2003
    Beiträge
    21

    Post boot.cryptmap - ein Bootskript zum mappen verschlüsselter Partitionen/Container-Files

    1. Beschreibung

    Anhang 14945

    Dieses Bootscript kümmert sich um das Mappen verschlüsselter Partitionen oder Container-Dateien auf entschlüsselte virtuelle Geräte (Crypto-Devices) unter /dev/mapper/*. Hierfür wird das dm_crypt Kernelmodul eingesetzt. Das Skript basiert auf SuSE's boot.crypto-Skript und wurde um folgende Funktionen erweitert:

    • Mehrere verschlüsselte Geräte, die mit dem selben Passwort verschlüsselt wurden, können so gruppiert werden, so dass das Passwort nur einmal abgefragt wird.
    • Swap-Partitionen können bei jedem Systemstart mit einem zufälligen Passwort aus /dev/random verschlüsselt werden. (Es muss kein Passwort eingegeben werden.)
    • Das Skript erkennt automatisch, ob ein Block-Device oder eine Datei gemappt werden soll und konfiguriert automatisch die benötigten Loop-Devices (/dev/loop*).
    • Das Skript ist so konzipiert, dass es ausgeführt werden kann, bevor die lokalen Dateisysteme gemountet werden. Somit kann die Definition auch der verschlüsselten Dateisysteme in der Datei /etc/fstab verbleiben.
    • Im Gegensatz zu SuSE's boot.crypto verwendet boot.cryptmap das Kernelmodul dm_crypt.


    Das Skript kann in den Bootprozess integriert werden, indem es in das Verzeichnis /etc/init.d kopiert wird. Um zu funktionieren, müssen lediglich zwei kleine Anpassungen an dem Skript, welches die lokalen Dateisysteme mountet, vorgenommen werden (s. u.). Das mitgelieferte Shell-Script „install.sh“ kann diese (und alle anderen) Installationsschritte automatisch durchführen.


    2. Anforderungen/Einschränkungen

    • dm_crypt muss vom Kernel unterstützt werden
    • Die Programme cryptsetup und losetup müssen vorhanden sein.
    • Das Skript wurde geschrieben und getestet unter SuSE Linux 10, sollte aber auch unter anderen Systemen (evtl. mit einigen Abweichungen vom hier geschilderten Installationsablauf) laufen, die das init.d-Bootkonzept unterstützen.
    • Container-Dateien mit verschlüsselten Dateisystemen müssen auf dem root-Dateisystem gespeichert sein.



    3. Verwendung

    Da es sich um ein Bootscript handelt, wird es normalerweise nicht direkt durch den Benutzer gestartet, sondern es wird aufgerufen, wenn das System hoch- oder herunterfährt. Die Installation wird im Abschnitt „Installation“ erklärt.
    Aber natürlich kann man das Skript auch direkt aufrufen. Falls es sich im Verzeichnis /etc/init.d befindet, würde das ungefähr so aussehen:

    Code:
    user@home:> /etc/init.d/boot.cryptmap <argument>
    Folgende Werte für <argument> sind zulässig:

    start
    Die Datei /etc/crypttab wird gelesen und die Mappings der verschlüsselten Geräte/Dateien auf die entschlüsselten Geräte unter /dev/mapper/* werden angelegt. Falls erforderlich, werden Passwörter abgefragt. Falls eine Container-Datei gemappt werden soll, werden Loop-Devices unter /dev/loop* automatisch angelegt und verwendet. Die Korrektheit des Passwortes wird dadurch überprüft, dass getestet wird, ob ein gültiges Dateisystem vorhanden ist. (Funktioniert z. Zt. nur für ext2/3 und reiserfs)

    stop
    Die Datei /etc/crypttab wird gelesen und die darin definierten Mappings in umgekehrter Reihenfolge entfernt. Dazugehörige Loop-Devices werden ebenfalls wieder entfernt.

    pre_stop
    Liest die Datei /etc/crypttab in umgekehrter Reihenfolge und entfernt lediglich die Mappings von Loop-Devices, damit das Root-Dateisystem ungemountet werden kann.

    Auf meiner SuSE-Installation sieht die Reihenfolge, in der die Skripte beim Hoch- und Herunterfahren aufgerufen werden folgendermaßen aus:

    boot:
    -> [...]
    -> boot.rootfsck start (lädt das Root-Dateisystem)
    -> boot.cryptmap start (liest /etc/crypttab, erzeugt die Mappings unter /dev/mapper/*)
    -> boot.localfs start (liest /etc/fstab, die restlichen Dateisysteme werden gemountet)
    -> [...]


    shutdown:
    -> [...]
    -> boot.cryptmap pre_stop (Loop-Devices werden unmountet und abgemeldet)
    -> boot.localfs stop (alle lokalen Dateisysteme werden ungemountet (inkl. root))
    -> boot.cryptmap stop (alle restlichen Mappings werden abgemeldet)
    -> [...]


    4. Installation

    Für die, die sich nicht den Strapazen einer manuellen Installation unterziehen wollen, gibt es das Skript „install.sh“, welches die im Folgenden beschriebenen Schritte automatisch durchführt und (falls etwas schief geht) Fehlermeldungen liefert. Für alle „Fußgänger“ hier die Installationsschritte:


    4.1. Dateien kopieren
    Kopiere die Datei „boot.cryptmap“ in das Verzeichnis /etc/init.d sowie die Datei „crypttab“ in das Verzeichnis /etc. Bei der Datei boot.cryptmap muss die Berechtigung zum Ausführen („x“) gesetzt sein. Vergiss nicht, Sicherheitskopien von allen Dateien anzufertigen, die Du überschreibst oder veränderst!


    4.2. Anpassen des Boot-Skripts, welches die lokalen Dateisysteme mountet
    boot.cryptmap muss beim Systemstart aufgerufen werden, bevor die lokalen Dateisysteme gemountet werden, damit dabei auch verschlüsselte Dateisysteme in /etc/fstab berücksichtigt werden können.
    Auf meinem System (SuSE10) wird das Mounten der lokalen Dateisystem vom Skript boot.localfs erledigt. Die Reihenfolge, in der die Skripte ausgeführt werden, wird dabei von Kommentarzeilen am Anfang der Skripte (vergl. „man insserv“) festgelegt. Es muss im Skript boot.localfs die Zeile, welche mit

    Code:
    # Required-Start: [... irgendwas...]
    beginnt, der Text „ boot.cryptmap“ am Ende eingefügt werden. Auf meinem System sieht diese Zeile nun so aus:

    Code:
    # Required-Start:    boot.rootfsck boot.cryptmap
    Dadurch wird insserv darüber informiert, dass das Skript boot.cryptmap unbedingt vor dem Skript boot.localfs ausgeführt werden muss.

    Die zweite Anpassung betrifft den Umstand, dass das Skript boot.localfs (anders als beim Hochfahren) beim Herunterfahren alle lokal gemounteten Dateisysteme, inklusive dem Root-Dateisystem, unmountet. Das ist insofern problematisch, dass das so lange nicht möglich ist, wie noch lokale Dateien als Loop-Devices eingerichtet sind.
    Deshalb muss boot.cryptmap mit dem Argument „pre_stop“ aufgerufen werden, bevor boot.localfs die Dateisysteme unmountet. Das ist gar nicht so schwer:
    Finde die Zeile, die mit

    Code:
    stop)
    beginnt und füge die Zeile

    Code:
    /etc/init.d/boot.cryptmap pre_stop #modifiziert für boot.cryptmap
    direkt als nächste Zeile dahinter ein.


    4.3. boot.cryptmap als interaktiv markieren
    Da das Skript Benutzereingaben (Passwörter) abfragt, muss es als interaktiv markiert werden, weil das System beim Hochfahren sonst einfach stehenbleibt. (Den Grund DAFÜR herauszufinden war gar nicht so einfach) Interaktive Boot-Skripte werden in der Konfigurationsdatei /etc/insserv.conf angemeldet. Suche hier nach der Zeile, die mit

    Code:
    <interactive> [... irgendwas ...]
    beginnt und füge den Text „ boot.cryptmap“ dahinter ein. Bei mir sieht diese Zeile nun so aus:

    Code:
    <interactive>   boot.crypto boot.localfs boot.rootfsck apache2 boot.cryptmap

    4.4. boot.cryptmap in den Bootprozess aufnehmen
    Nachdem sich alle Dateien an ihrem Platz befinden und alle Modifikationen durchgeführt wurden, müssen im Verzeichnis /etc/init.d/boot.d zwei symbolische Links auf boot.cryptmap gesetzt werden. Durch die Namen der Links wird die Position festgelegt, in der sie beim Starten/Herunterfahren aufgerufen werden. Zum Glück muss hier nicht tief ins Detail gegangen werden, denn das Programm „insserv“ erledigt das ganz automatisch. Führe einfach folgendes Kommando aus:

    Code:
    user@host:> insserv boot.cryptmap
    Wenn das funktioniert hat, befinden sich nun zwei neue Links im Verzeichnis /etc/init.d/boot.d. Mit folgendem Befehl kannst Du das überprüfen:

    Code:
    user@host:> ls -la /etc/init.d/boot.d/[KS][0-9][0-9]boot.cryptmap
    
    lrwxrwxrwx  1 root root 16 2006-02-19 12:03 /etc/init.d/boot.d/K17boot.cryptmap -> ../boot.cryptmap
    lrwxrwxrwx  1 root root 16 2006-02-19 12:03 /etc/init.d/boot.d/S07boot.cryptmap -> ../boot.cryptmap
    Sooo... das wars auch schon!


    5. Konfigurieren

    Falls Du bereits verschlüsselte Dateisysteme mit dm_crypt erzeugt hast, kannst Du nun die Datei „/etc/crypttab“ anpassen, um diese beim Hochfahren automatisch einzubinden. Der Aufbau dieser Datei orientiert sich stark an dem anderer Konfigurationsdateien wie z. B. fstab oder auch cryptotab. In jeder Zeile wird genau ein Mapping definiert, Kommentarzeilen beginnen mit „#“. Es sind sechs Parameter notwendig, die durch Leerzeichen oder Tabstopps zu trennen sind:

    cryptname
    der Name, unter dem das entschlüsselte Gerät in /dev/mapper/ erscheinen soll

    device
    das verschlüsselte Gerät oder die verschlüsselte Datei

    cipher
    der Verschlüsselungsalgorithmus (z. B. AES)

    keylength
    die Länge des Schlüssels (z. B. 256 bit)

    filesystem
    das Dateisystem (z. B. ext3, reiserfs, swap); Mit dieser Angabe wird lediglich die Eingabe des korrekten Passwortes überprüft. (Das Mounten übernimmt ein anderes Skript.)

    pwgroup
    Die Passwortgruppe (frei wählbar oder „random“). Falls mehrere Mappings der selben pwgroup angehören, wird das Passwort nur einmal abgefragt. Bei Mappings der pwgroup „random“ wird kein Passwort abgefragt, sondern /dev/random zur Passwortgenerierung genutzt (nützlich bei verschlüsselten Swap-Partitionen).


    Ausführlichere Informationen zu den einzelnen Parametern und einige Beispiele finden sich in der mitgelieferten /etc/crypttab.


    6. Weiterführende Informationen

    Sehr viele Infos und Anleitungen zum Thema Verschlüsselung mit dm_crypt befinden sich im dm_crypt-Wiki unter http://www.saout.de/tikiwiki. Wenn es auf Deutsch sein soll, dann schau Dich einfach mal ein wenig hier im Forum um (SuFu oder Unterforum Sicherheit).


    7. Zum Schluss

    Über Kommentare/Anmerkungen/Hinweise würde ich mich freuen!
    Geändert von Yeat (21.02.06 um 20:45 Uhr)

Ähnliche Themen

  1. COD Server Problemm
    Von Iron im Forum Dedizierte Spiele Server
    Antworten: 4
    Letzter Beitrag: 25.09.05, 13:41
  2. Antworten: 6
    Letzter Beitrag: 20.03.05, 09:45
  3. Skriptfehler Debian
    Von Tuxist im Forum Spielen Allgemein
    Antworten: 9
    Letzter Beitrag: 23.12.04, 19:27
  4. rtcw + et stürtzen ab + schlechte performence
    Von Tuxist im Forum Spielen Allgemein
    Antworten: 2
    Letzter Beitrag: 02.12.04, 11:40
  5. Quake3 Ra3
    Von Nikkita im Forum Spielen Allgemein
    Antworten: 9
    Letzter Beitrag: 10.04.04, 15:00

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •