debianforum.de

Nabend zusammen,

Ich möchte gerne ein Debian 9 System verschlüsseln und das möglichst mit der Boot-Partition. Wäre jemand so lieb mir das möglichst anfängerfreundlich zu erklären?

Anleitungen hab ich einige gefunden, allerdings wird da ein USB Stick als Boot-Partition genutzt. Da ich gerne mal was verliere und der Stick auch den Geist aufgeben könnte ist das keine Option für mich.

Auf einem englischen Blog habe ich gesehen, dass es wohl über Umwege auch möglich ist, die Boot Partition auf der SSD mit dem restlichen System zu verschlüsseln. Leider ist mein Englisch "not the yellow from the egg" und ich habe den Post auch grad nicht zur Hand, den ich meine.

Wäre echt klasse wenn mir das jemand von der Partitiontabelle an erklären könnte. Wüsste auch gerne ob ich Debian im Legacy, oder UEFI Modus installieren sollte.

Gruß Ralle

Hallo und willkommen im Forum,
da hast du dir ganz schön was vorgenommen ...

Ich fand die folgende Anleitung ganz interessant: http://www.pavelkogan.com/2014/05/23/lu ... ncryption/ . Hab sie selber nie ausprobiert, weil ich den Mehrwert der /boot Verschlüsselung in meinem persönlichen Threat-Szenario nicht erkenne. Aber das kann bei dir ja anders sein. Falls dein Englisch nicht ausreicht kann dir Google Übersetzer wahrscheinlich weiter helfen.
Zum Üben würde ich weit weg von einem System mit wichtigen Daten gehen und das Ganze bspw. in einer virtuellen Maschine mal durchspielen.

@spiralnebelverdreher

Seine Anleitung ist für Arch wenn ich das recht verstehe und leider geht er auch nicht weiter auf das Partitionieren vor der Verschlüsselung ein. Dennoch Danke für deinen Post. Ich schaue mal ob ich mir was nützliches aus der Anleitung rausziehen kann.

ralle77 hat geschrieben:

11.01.2018 22:55:56

Seine Anleitung ist für Arch wenn ich das recht verstehe und leider geht er auch nicht weiter auf das Partitionieren vor der Verschlüsselung ein.

Nachdem ich das kurz überflogen habe, fällt mir zuerst ganz oben sein Hinweis auf, dass er eine ähnliche Anleitung für Linux Mint geschrieben hat. Mint ist wesentlich Debian-ähnlicher ... leider ist seine Anleitung für Mint aber noch wirrer.

Zweitens zur Partitionierung: Die "Kurzanleitung" steht gleich im ersten Code-Block. Wenn ich das recht verstehe, erzeugt er eine große Partition über die gesamte Festplatte. In dieser Partition legt er dann ein LVM an mit root, home und swap. Eine eigene Boot-Partition existiert also gar nicht, auch nicht im LVM.

Das ist der standard verschlüsselten Debian-Installation sehr ähnlich. Debian legt hier eine unverschlüsselte Boot-Partition an und packt alles andere in ein verschlüsseltes LVM.

Somit würde ich mit einem verschlüsselten Debian anfangen. Du müsstest im laufenden Betrieb die Partition /boot unmounten, dann nach z.B. /mnt mounten, und die Boot-Daten von /mnt/ in das (verschlüsselte) Verzeichnis /boot kopieren. Auf einem UEFI-System musst du dich zusätzlich noch um die Mounts von /boot/efi/ kümmern.

Danach müsstest du Grub beibringen, von der verschlüsselten root-Partition zu booten, statt von der unverschlüsselten Boot-Partition. Hierbei müsstest du nach seiner Arch-Anleitung vorgehen. Wenn das klappt, kannst du die unverschlüsselte Boot-Partition löschen und mit Bildern von Edward Snowden vollschreiben. Wenn es nicht klappt, hast du hoffentlich eine "SuperGrub2Disk" zur Hand, um die Kiste doch noch zu booten.

Der Rest seiner Anleitung dreht sich darum, wie du es verhinderst, das Passwort zwei mal einzugeben. Wenn du soweit bist, hast du es eigentlich schon geschafft. Darum dreht sich auch seine gesamte Mint-Anleitung. Die besteht im Wesentlichen daraus, dass die "<key file>"-Option nicht funktioniert - tut sie aber meineswissens in Debian. Schau dir dazu lieber "man crypttab" an und hier im Wiki findest du ein weiteres Beispiel. Die andere Hälfte besteht daraus, wie man die Schlüssel-Datei in die Initramdisk kopiert ... lass dich dazu lieber hier inspirieren:
https://unix.stackexchange.com/question ... ian-wheezy

Und wie spiralnebelverdreher schon sagte ... ich würd's auf ner leeren Festplatte oder VM üben ...

Edit: Ach so ... wäre eine einmalbeschreibbare CD-ROM als unverschlüsseltes Bootmedium eine Option?

Hier ist, wie die Debian-Leute das sehen:
https://wiki.debian.org/Grub2#Configure ... ed_.2Fboot

Testen würde ich das zuerst auch in einer VM und beachte bei der 1. Passworteingabe (für /boot): Grub2 Stage 1 hat nur ein US-Keyboard-Layout.

tobo hat geschrieben:

12.01.2018 01:01:56

Hier ist, wie die Debian-Leute das sehen:
https://wiki.debian.org/Grub2#Configure ... ed_.2Fboot

Testen würde ich das zuerst auch in einer VM und beachte bei der 1. Passworteingabe (für /boot): Grub2 Stage 1 hat nur ein US-Keyboard-Layout.

Aus eigener Erfahrung funktioniert das recht gut. Was eher ungünstig ist, ist der Umstand, nun zwei Passwörter beim Systemstart eingeben zu müssen. Einmal für das Boot-Volume und dann nochmals für das Root-Volume. Hatte in der Vergangenheit versucht, dass mit Schlüsseldateien für das Root-Volume zu lösen, jedoch ohne echten Erfolg. Mit dem Keyboard-Layout hatte ich noch kein Problem, bzw. hier war es immer auf deutsch. Alternativ könnte man das auch via /etc/default/grub festsetzen, falls dem einmal nicht so sein sollte.

Ja, unter diese 2 Passwörter hab ich das auch nicht geschafft. Bei mir war kein LVM und /boot hat nicht in einer separaten Partition gelegen!? Diesen letzten Punkt wollte ich mal noch irgendwann geändert testen. Was das Keyboard angeht, das kann ich so nur schwer glauben!? Zunächst mal steht es in der doc von grub selbst, dass es auf US-Tastatur beschränkt ist und zusätzlich kann ich mir auch nicht vostellen, dass man über /etc/default/grub stage 1 konfigurieren kann!?

Danke für eure zahlreichen Antworten! Werde mich das Wochenende mal dransetzen.

Auf eine UEFI Installation kann ich getrost verzichten, da Debian momentan noch kein Secure Boot unterstützt und es auch sonst keine großartigen Vorteile mit sich bringt, richtig?

ralle77 hat geschrieben:

12.01.2018 14:31:17

Auf eine UEFI Installation kann ich getrost verzichten, da Debian momentan noch kein Secure Boot unterstützt und es auch sonst keine großartigen Vorteile mit sich bringt, richtig?

Hier und jetzt hast du recht.

Secure Boot könnte man sich mühseelig zurechtbasteln und hoffen, dass es Updates übersteht. Und Intel hat rumgeblubbert, dass zukünftige Mainboards kein Legacy/BIOS-Boot mehr unterstützen werden. Fragt sich, wie "zukunftssicher" du die Kiste aufsetzen willst ...

NAB hat geschrieben:

12.01.2018 16:24:12

Secure Boot könnte man sich mühseelig zurechtbasteln und hoffen, dass es Updates übersteht. Und Intel hat rumgeblubbert, dass zukünftige Mainboards kein Legacy/BIOS-Boot mehr unterstützen werden. Fragt sich, wie "zukunftssicher" du die Kiste aufsetzen willst ...

Naja ich setze mein System in der Regel neu auf wenn ich die Kiste/Hardware wechsel.
Demnach für den Zeitraum lieber bombensicher statt zukunftssicher.

Mag jemand mal über folgendes Skript drüberschauen:
https://github.com/cmhamill/workstation ... tomounting

ralle77 hat geschrieben:

12.01.2018 16:47:17

Mag jemand mal über folgendes Skript drüberschauen:
https://github.com/cmhamill/workstation ... tomounting

Was soll man da schauen? Es ist kein eigenständiges Script, sondern greift auf ../lib/lib.sh zurück.
Das "Configure an existing encrypted \`/boot' partition " hast du gesehen?
Du bräuchtest also erst mal eine eigene verschlüsselte Partition für /boot.

NAB hat geschrieben:

12.01.2018 17:48:07

Was soll man da schauen? Es ist kein eigenständiges Script, sondern greift auf ../lib/lib.sh zurück.
Das "Configure an existing encrypted \`/boot' partition " hast du gesehen?
Du bräuchtest also erst mal eine eigene verschlüsselte Partition für /boot.

Recht hast du. Ich wollte im Endeffekt nur wissen, ob es den Zweck des Automounts auch erfüllt.
Ich selber kann das leider nicht wirklich beurteilen.

NAB hat geschrieben:

12.01.2018 00:50:26

Edit: Ach so ... wäre eine einmalbeschreibbare CD-ROM als unverschlüsseltes Bootmedium eine Option?

Blöde Frage, aber wie sieht es dann bei Updates aus?
Die CD ist ja nach dem beschreiben sozusagen "read only".

Wenn ich zB einen USB Stick als /boot verwende, würde es reichen mir diesen einmalig auf einen Backup Stick zu spiegeln, oder müsste ich das bei jedem Update neu spiegeln?

ralle77 hat geschrieben:

12.01.2018 20:43:19

Blöde Frage, aber wie sieht es dann bei Updates aus?
Die CD ist ja nach dem beschreiben sozusagen "read only".

Die Frage ist nicht blöd sondern ziemlich gut. Bei jedem Update, das das Bootsystem betrifft, also Kernel oder Grub, müsstest du eine neue CD anfertigen. Die Updates selber landen in einem (verschlüsselten) /boot-Verzeichnis in deiner verschlüsselten root-Partition und dienen als Vorlage für die neue CD. Ein "Angreifer" findet in ausgeschaltetem Zustand nur noch eine riesige verschlüsselte Partition und eine "read only" CD, also gar kein veränderbares Bootsystem mehr, vor. Ja, diese Lösung ist aufwendig und paranoid ... ich weiß ja nicht, ob du gerade vor der NSA flüchtest oder nur deinen kleinen Bruder abwehren willst.

ralle77 hat geschrieben:

12.01.2018 20:43:19

Wenn ich zB einen USB Stick als /boot verwende, würde es reichen mir diesen einmalig auf einen Backup Stick zu spiegeln, oder müsste ich das bei jedem Update neu spiegeln?

Eh ... reichen für was? Solange du Debian Stable verwendest, wirst du mit dem alten Backup im Notfall sicherlich noch booten können, aber dann eventuell mit einem alten Kernel mit Sicherheitslücken.

Die spannende Frage hierbei ist: wo landen die Updates? Wenn du den anderen USB-Stick wirklich permanent als /boot eingebunden hast, dann landen die Updates direkt auf dem USB-Stick. Wenn du dann den veralteten USB-Stick einsteckst, dann merkt das System gar nicht, dass es wieder mit einem veralteten Kernel unterwegs ist - die Datenbank sagt ja, dass alle Pakete auf dem neusten Stand sind. Gut, dass lässt sich reparieren, durch ein "reinstall" ... man muss aber dran denken. Oder sich Scripte basteln ...

NAB hat geschrieben:

12.01.2018 21:16:02

Eh ... reichen für was? Solange du Debian Stable verwendest, wirst du mit dem alten Backup im Notfall sicherlich noch booten können, aber dann eventuell mit einem alten Kernel mit Sicherheitslücken.

Die spannende Frage hierbei ist: wo landen die Updates? Wenn du den anderen USB-Stick wirklich permanent als /boot eingebunden hast, dann landen die Updates direkt auf dem USB-Stick. Wenn du dann den veralteten USB-Stick einsteckst, dann merkt das System gar nicht, dass es wieder mit einem veralteten Kernel unterwegs ist - die Datenbank sagt ja, dass alle Pakete auf dem neusten Stand sind. Gut, dass lässt sich reparieren, durch ein "reinstall" ... man muss aber dran denken. Oder sich Scripte basteln ...

Nehmen wir mal an, ich würde den Stick aus Bequemlichkeit stecken lassen.

Die einfachste Lösung wäre ja dann, dass /boot sowohl auf der Root Partition, als auch auf dem Stick Updates bekommt. Wenn du mir sagen könntest wie ich das mit einem Skript realisieren kann, wäre das saustark.

Also wenn du jetzt eine Fertiglösung erwartest - ich hab keine. Ich hab sowas auch noch nie gemacht.

Wenn die Updates eh im verschlüsselten Bereich der Festplatte landen, dann braucht der USB-Stick auch nicht permanent eingesteckt zu sein. Man könnte prüfen ob er vorhanden ist und ihn nach /bootbackup mounten.
Die Hauptarbeit, das Kopieren, lässt mich mit einem einfach "cp" erledigen. Danach wird's fummelig.
/bootbackup müsste geunmounted werden und dann als /boot gemounted werden. Danach sollte ein update-grub und ein grub-install /dev/sdX deinen USB-Stick eigentlich bootfähig machen. Danach muss /boot wieder geunmounted werden.

Die nächste spannende Frage ist, wann man das Script ausführt. Eine Methode, sich direkt in die Updates einzuklinken kenne ich nicht. Man könnte das /boot-Verzeichnis mit inotify überwachen. Oder das Script einfach bei jedem Herunterfahren ausführen, dabei wäre Systemd hilfreich:
https://unix.stackexchange.com/question ... e-shutdown

Aber weiter oben hast du einen USB-Stick noch ausgeschlossen. Ich sehe da auch keinen Vorteil ... vorallem wenn er permanent eingesteckt ist. Du kannst /boot auch auf dem USB-Stick verschlüsseln, um eine kleinere Angriffsfläche zu bieten ... hast aber immer noch einen unverschlüsselten und manipulierbaren Grub auf dem USB-Stick. Das gleiche Ergebnis erzielst du mit einem verschlüsselten /boot auf der Festplatte.

Alternative: du speicherst nur den Grub auf dem USB-Stick. Der entschlüsselt und startet dann /boot von der Festplatte. Das müsste sich mit dem Debian-Installer im manuellen Modus sogar gleich bei der Installation so einrichten lassen (bis auf das verschlüsselte /boot).

NAB hat geschrieben:

12.01.2018 22:30:18

Also wenn du jetzt eine Fertiglösung erwartest - ich hab keine. Ich hab sowas auch noch nie gemacht.

Wenn die Updates eh im verschlüsselten Bereich der Festplatte landen, dann braucht der USB-Stick auch nicht permanent eingesteckt zu sein. Man könnte prüfen ob er vorhanden ist und ihn nach /bootbackup mounten.
Die Hauptarbeit, das Kopieren, lässt mich mit einem einfach "cp" erledigen. Danach wird's fummelig.
/bootbackup müsste geunmounted werden und dann als /boot gemounted werden. Danach sollte ein update-grub und ein grub-install /dev/sdX deinen USB-Stick eigentlich bootfähig machen. Danach muss /boot wieder geunmounted werden.

Die nächste spannende Frage ist, wann man das Script ausführt. Eine Methode, sich direkt in die Updates einzuklinken kenne ich nicht. Man könnte das /boot-Verzeichnis mit inotify überwachen. Oder das Script einfach bei jedem Herunterfahren ausführen, dabei wäre Systemd hilfreich:
https://unix.stackexchange.com/question ... e-shutdown

Aber weiter oben hast du einen USB-Stick noch ausgeschlossen. Ich sehe da auch keinen Vorteil ... vorallem wenn er permanent eingesteckt ist. Du kannst /boot auch auf dem USB-Stick verschlüsseln, um eine kleinere Angriffsfläche zu bieten ... hast aber immer noch einen unverschlüsselten und manipulierbaren Grub auf dem USB-Stick. Das gleiche Ergebnis erzielst du mit einem verschlüsselten /boot auf der Festplatte.

Alternative: du speicherst nur den Grub auf dem USB-Stick. Der entschlüsselt und startet dann /boot von der Festplatte. Das müsste sich mit dem Debian-Installer im manuellen Modus sogar gleich bei der Installation so einrichten lassen (bis auf das verschlüsselte /boot).

Erwartungen stell ich gar keine. Ich wollte nur auf einen Ansatz hinaus,
wie man das angehen könnte, da du dich scheinbar ganz gut auskennst.
Habe gehofft die Updates lassen sich direkt abgreifen.

Klar ein Boot Stick, der permanent steckt, macht sicherheitstechnisch wenig Sinn.
Hätte den Stick dann halt abgezogen, wenn ich nicht am Rechner bin.

Ich probiere es mal mit Grub auf dem Stick und Boot auf der verschlüsselten Platte.
Das klingt vernünftig und ist mit wenig Aufwand verbunden.

Danke für die ausführliche Aufklärung!

Ja ... ich grübele, wie man das beste Ergebnis am leichtesten hinbekommt. Das umherkopieren von /boot finde ich weder leicht noch sinnvoll. Schick wäre es hingegen, wenn deine gesamte Festplatte nur noch aus einer riesigen verschlüsselten Partition besteht, die nicht mal mehr Platz für einen manipulierten Bootmanager lassen würde. Noch schicker wäre es, wenn man das gleich mit dem Debian-Installer hinkriegen würde ... darauf wollte ich schon in meinem ersten Posting hinaus. Sonst steht viel nervige Handarbeit mit chroot und debootstrap an.

Meine grobe Idee sieht inzwischen so aus:
Du legst auf dem USB-Stick zwei Partitonen an - eine winzige für Grub ("grub_bios" für BIOS oder "esp" für UEFI) und eine etwas größere für ein unverschlüsseltes /boot. Auf die Festplatte kommt eine einzige verschlüsselte Partition für den Rest ... LVM würde ich mir sparen.

Das kannst du so mit dem Debian Installer per "manueller Partitionierung" einrichten und der Debian Installer müsste dir dann ein bootfähiges Debian auf USB-Stick und Festplatte legen. Du musst ihm noch sagen, dass er das grub-install auf dem USB-Stick durchführen soll - das geht aber auch nachher manuell.

Danach machst du weiter wie hier angedeutet:
viewtopic.php?f=37&t=168249#p1160370

Die unverschlüsselte Boot-Partition auf dem USB-Stick kannst du nachher überschreiben und einstampfen.

Ergebnis:
Der Rechner bootet nur vom USB-Stick. Auf dem USB-Stick ist Grub inklusive Grub-Partition.
Auf der Festplatte ist nur eine riesige verschlüsselte Partition.

Selbst wenn dein kleiner Bruder den Rechner heimlich auf Booten von Festplatte umstellt, wird er keinen manipulierten standard Grub installieren können, weil dafür kein Platz ist. Die NSA würde natürlich trotzdem maßgeschneiderte Wege finden.

tobo hat geschrieben:

12.01.2018 12:29:39

Ja, unter diese 2 Passwörter hab ich das auch nicht geschafft. Bei mir war kein LVM und /boot hat nicht in einer separaten Partition gelegen!? Diesen letzten Punkt wollte ich mal noch irgendwann geändert testen.

Ich habe hier eine 2TB HDD. Die ersten 2GB werden als primäre Partition genutzt, und damit für das Boot-Volume. Dann kommt eine weitere logische Partition von 200GB mit LVM-Volumes, die das restliche System in mehrere Segmente aufteilen. Der Rest wird für diverse Daten-Volumes genutzt. Und das Boot-Volume ist gemäß des Debian-Wikis nachträglich verschlüsselt worden.

Was mir nicht wirklich einleuchtet ist, warum es nicht funktioniert, dass Root-Volume mittels einer Schlüsseldatei auf dem zuvor gemounteten Boot-Volume zu entschlüsseln. Zumal sich das Cryptsetup dann so verhält, als würde das Boot-Volume garnicht existieren und somit auch keine Schlüsseldatei. Normalerweise müsste die Schlüsseldatei doch über denen Mountpoint /boot erreichbar sein, was hier aber offenbar nicht der Fall ist. Möglicherweise wird aber auch zu früh nach der Schlüsseldatei gesucht, bevor das Boot-Volume bereit ist. Nur wie könnte der Linux-Kernel geladen werden, wenn dem nicht so wäre? Das Problem ist einfach, dass es in dem frühen Stadium beim Systemstart keine Logs gibt.

tobo hat geschrieben:

12.01.2018 12:29:39

Was das Keyboard angeht, das kann ich so nur schwer glauben!? Zunächst mal steht es in der doc von grub selbst, dass es auf US-Tastatur beschränkt ist und zusätzlich kann ich mir auch nicht vostellen, dass man über /etc/default/grub stage 1 konfigurieren kann!?

Stimmt, dass geht doch erst ab Stage 2, gerade wenn das Boot-Volume verschlüsselt ist. Diesbezüglich müsste ich bezüglich meiner Passwörter einen ziemlichen Dusel gehabt haben, wenn es bei dem englischen Keyboard-Layout noch kein Problem gab.

breakthewall hat geschrieben:

13.01.2018 03:54:08

Was mir nicht wirklich einleuchtet ist, warum es nicht funktioniert, dass Root-Volume mittels einer Schlüsseldatei auf dem zuvor gemounteten Boot-Volume zu entschlüsseln.

Warum sollte /boot überhaupt gemounted sein? Und von wem? Grub braucht den Inhalt von /boot ... aber Grub mounted nichts. Es startet den Kernel und der mounted die Initrd. Und die sucht erst mal das richtige root-Dateisystem ...

NAB hat geschrieben:

13.01.2018 04:37:15

Warum sollte /boot überhaupt gemounted sein? Und von wem? Grub braucht den Inhalt von /boot ... aber Grub mounted nichts.

Als erstes muss Grub das Volume entschlüsseln. Doch zugegriffen kann auf dessen Daten erst, nachdem das Volume gemountet wurde. Ich sehe aber gerade das ich mich ohnehin vertan habe, da das Cryptsetup nicht das Fehlen der Schlüsseldatei bemängelte, sondern in dieser Konfiguration kein Root-Volume finden kann, wenn es via Schlüsseldatei entschlüsselt werden soll. Und ich denke nun zu wissen warum. Es wird nichts gefunden weil der ganze Vorgang zu schnell abläuft, sprich die LVM-Volumes wurden noch garnicht erkannt, weshalb Grub auch nichts finden kann. Das lässt sich mit "rootdelay=X" in der Kernelzeile ändern, um der LVM-Erkennung mehr Zeit zu verschaffen. Muss das mal austesten, da das mitunter etwas dauern kann.

ralle77 hat geschrieben:

11.01.2018 22:24:28

Ich möchte gerne ein Debian 9 System verschlüsseln und das möglichst mit der Boot-Partition. Wäre jemand so lieb mir das möglichst anfängerfreundlich zu erklären?

Anfängerfreundlich? Fang mit dem an, was dir der Installer einrichtet: verschlüsseltes LVM, das von unverschlüsselten /boot startet.

Wenn du das ausreichend verstanden hast (und kein Anfänger mehr bist ), dann weißt du, weshalb verschlüsseltes /boot eine ziemlich unpraktische Sache ist, die ziemlich wenig bringt. Oder aber du weißt, wie du dieses System zu verschlüsseltem /boot weiterentwickeltst.