Debian 11 Verschlüsselung der Systempartion u.a. Volumes

[ruth]

Hallo zusammen,

ich habe Debian 11 in einer VM (VirtualBox 6.1) installiert, mit dem Ziel die Verschlüsselung aller Partitionen einzurichten.

Leider ist mir das nicht gelungen. Wo könnte der Fehler liegen?

Für hilfreiche Tipps, Danke voraus.

[schwedenmann]

Hallo

Und iw bist du vorgegangen ?


mfg
schwedenmann

[ruth]

Hallo,

bei der Installation | "Geführt - gesamte Platte mit verschlüsseltem LVM"

habe ich ausgewählt.

Danke voraus.

[rhHeini]

Ich bau mir meine Verschlüsselung immer manuell, hab diesen Automatismus noch nie verwendet. Ich rate mal: /boot ist nicht verschlüsselt, oder? Das ist der klassische Ansatz.

[ruth]

Ich versuche es mal mit mit der Anleitung.

https://www.dwarmstrong.org/minimal-debian/

[rhHeini]

Nach dieser Anleitung bekommst Du eine unverschlüsselte /boot.

[ruth]

Danke. Ich kann auf jeden Fall berichten das die Anleitung einwandfrei funktioniert.

Jetzt müsste ich nur wissen welchen Nachteil es haben sollte das die /boot nicht verschlüsselt ist.

viewtopic.php?t=180632

Danke wieder voraus.

[cosinus]

Jetzt müsste ich nur wissen welchen Nachteil es haben sollte das die /boot nicht verschlüsselt ist.

Warum verschlüsselst du denn? Damit wohl kein Unbefugter an deine privaten Daten kommt, wenn dein Gerät geklaut wird. Und nun frage dich: was legt man an privaten schützenswerten Daten in /boot ab?

[ruth]

Ausschließlich Diebstahlschutz ist der Grund für die Verschlüsselung.

[ruth]

Hallo,

Problem war bei mir das ich eine NFTS Partion auf dem Laufwerk habe. Ich hab auf der Maschine auf einer andere Platte noch WIndows am laufen.

Mit der automatischen Verschlüsselung funktionierte das leider nicht, da das ganze Volume verschlüsselt wird.
Das konnte auch nicht mehr mit gparted im nachhinein geändert werden.

Also hab ich mich entschieden die manuelle Installation duruchzuführen.

Dazu war für mich die n.s. Anleitung hilfreich | https://andwil.de/weblog/debian-verschl ... artitionen

[hikaru]

was legt man an privaten schützenswerten Daten in /boot ab?

Den Kernel und die initrd.
Bei unverschlüsseltem /boot könnte die im Prinzip jemand gegen kompromittierte Versionen austauschen, die dann das System zu (von dir) ungewünschtem Verhalten motivieren.
(Dieses Szenario ist übrigens einer der Selling Points von Secure Boot, denn das würde das Booten eines manipulierten Kernels verhindern.)

[cosinus]

Ich glaub @ruth ging es darum, dass ein Dieb nicht an ihre privaten Daten rankommt.
Was ist denn als Alternative das hier? -> https://www.thomas-krenn.com/de/wiki/AT ... eature_Set

[ruth]

Hallo, ATA Security Feature Set hatte ich mich mit einem Kollegen vor zwei Tagen drüber unterhalten.

Er hat mir erzählt das er einen guten Rechner günstig ersteigert hatte, weil das BIOS mit Passwort gesichert war.

Es konnte es wohl knacken.

[hikaru]

Ich glaub @ruth ging es darum, dass ein Dieb nicht an ihre privaten Daten rankommt.

Schon klar, aber was ein System das auf einem kompromittierten Kernel läuft mit deinen Daten anstellt, hast du halt nicht unter Kontrolle. Der Kernel steuert z.B. den Tastatur-, und den Netzwerktreiber, könnte also z.B. als Remote-Keylogger missbraucht werden.

[MSfree]

(Dieses Szenario ist übrigens einer der Selling Points von Secure Boot, denn das würde das Booten eines manipulierten Kernels verhindern.)

Irgendwie glaube ich nicht daran. Secure Boot würde nur das Laden eines manipulierten Grub verhindern. Was Grub danach macht, ist nicht mehr unter der Kontrolle von UEFI und damit werden auch keine Signaturen mehr geprüft. Grub könnte also auch einen manipulierten Kernel booten.

[hikaru]

Secure Boot würde nur das Laden eines manipulierten Grub verhindern.

Du kannst über UEFI auch direkt den Kernel booten, ganz ohne Grub.

Was Grub danach macht, ist nicht mehr unter der Kontrolle von UEFI und damit werden auch keine Signaturen mehr geprüft. Grub könnte also auch einen manipulierten Kernel booten.

Die Idee von Secure Boot in Verbindung mit Grub ist wohl, dass auch Grub seinerseits eine Signaturprüfung des Kernels durchführen soll.
Tauschst du den Kernel gegen einen Unsignierten aus, dann meckert Grub. Tauschst du (auch) Grub aus, dann meckert das UEFI. So soll eine "Chain of Trust" enstehen, wo jede Komponente ihren Nachfolger prüft.

Das habe ich aber alles nur aufgeschnappt. Bei mir läuft soweit möglich überall noch Legacy Boot.
Worauf ich hinaus wollte: Man kann mit dem Argument "Privatsphäre" für eine Verschlüsselung von /boot argumentieren, auch wenn dort nicht direkt private Daten abgelegt werden.

[MSfree]

Du kannst über UEFI auch direkt den Kernel booten, ganz ohne Grub.

Richtig. Allerdings habe ich im Debianinstaller diese Option noch nicht gesehen.

...So soll eine "Chain of Trust" enstehen, wo jede Komponente ihren Nachfolger prüft.

Soviel zur Theorie. Man kann aber ein Linuxsystem auch ziemlich einfach über die initrd kompromitieren. Meines Wissens wird die initrd nicht signiert. Man könnte also einfach irgendwelche Schadprogramme im Userspace von der initrd starten.

Bei mir läuft soweit möglich überall noch Legacy Boot.

Ich nutze durchaus UEFI-Boot, habe aber secure Boot grundsätzlich aus, weil es eben keinen wirksamen Schutz gegen Manipulation bietet. Im Zweifelsfall sperrt man sich nur unnötig aus.

Worauf ich hinaus wollte: Man kann mit dem Argument "Privatsphäre" für eine Verschlüsselung von /boot argumentieren, auch wenn dort nicht direkt private Daten abgelegt werden.

Irgendwas muß letztlich unverschlüsselt bleiben, sei es nur der Code zu Eingabe eines Passwortes. Damit hat man am Ende immer einen Hebel, Sicherheitsmaßnahmen zu umgehen.

[jph]

ich habe Debian 11 in einer VM (VirtualBox 6.1) installiert, mit dem Ziel die Verschlüsselung aller Partitionen einzurichten.

Leider ist mir das nicht gelungen. Wo könnte der Fehler liegen?

Du hast, wie ich der anderen Antwort entnehme, den Standard-Weg über den Installer eingeschlagen. Der richtet dir ein unverschlüsseltes /boot ein und legt alle anderen Dateisysteme und swap in einem LVM an, dessen PV wiederum verschlüsselt ist.

Passt soweit als Schutz der persönlichen Daten bei Verlust des Laptops. Erprobt, zuverlässig, nutze ich seit 15+ Jahren auf meinen Rechnern. Aluhutdiskussionen lassen wir mal weg.

Du schreibst, dass dir das nicht gelungen sei. Was ist denn nicht gelungen? Installation abgebrochen? Verschlüsselung nicht eingerichtet? Oder was? Woran machst du das fest?

[ruth]

Hallo,

vielen Dank.

Das Problem wurde gelöst. | viewtopic.php?p=1322634#p1322611

[cosinus]

Schon klar, aber was ein System das auf einem kompromittierten Kernel läuft mit deinen Daten anstellt, hast du halt nicht unter Kontrolle. Der Kernel steuert z.B. den Tastatur-, und den Netzwerktreiber, könnte also z.B. als Remote-Keylogger missbraucht werden.

Darum ging es doch garnicht. Es ging darum, dass ein Dieb nicht an ihre Daten kommt. Oder glaubst du der Dieb gibt das Notebook nach dem Diebstahl einfach zurück und tut so als sei nichts, dabei hat er aber /boot manipuliert?

[cosinus]

Man kann mit dem Argument "Privatsphäre" für eine Verschlüsselung von /boot argumentieren, auch wenn dort nicht direkt private Daten abgelegt werden.

Man kann das ja mit dem Festplattenpasswort kombinieren wenn einem das so wichtig ist, dass auch niemand an /boot herankommt.
Unter Windows hat man doch genau das gleiche Problem: Bitlocker verschlüsselt "nur" Laufwerk C aber nicht das Bootvolume.

[DeletedUserReAsG]

Irgendwas muß letztlich unverschlüsselt bleiben, sei es nur der Code zu Eingabe eines Passwortes.

Man kann auch /boot auf einen USB-Datenträger tun, und immer bei sich tragen. Dann ist die Frage, inwiefern die Firmware keine Backdoors oder sonstige „Fehler“ hat. Gibt in der Tat immer einen Weg; ob der praktisch gehbar ist, wäre eine andere Frage.

Aber das als Vorwand zu nehmen, gleich völlig auf den Schutz der Daten zu verzichten, wie’s einige Gestalten hier im Forum ja von Zeit zu Zeit vorschlagen, halte ich dann für nicht völlig zu Ende gedacht. Mit jedem Schritt höher macht man es einem Angreifer schwerer. Und wer meint, dass es nur um den gemeinen Dieb oder so ginge, der möge sich mal die Polizeigesetze mancher Bundesländer ansehen, und vielleicht langsam mal seiner naiven Vorstellung einen Realitätscheck entgegenstellen.

[hikaru]

Schon klar, aber was ein System das auf einem kompromittierten Kernel läuft mit deinen Daten anstellt, hast du halt nicht unter Kontrolle. Der Kernel steuert z.B. den Tastatur-, und den Netzwerktreiber, könnte also z.B. als Remote-Keylogger missbraucht werden.

Darum ging es doch garnicht.

Doch genau darum ging es:

Es ging darum, dass ein Dieb nicht an ihre Daten kommt.

Ein Dieb der einmalig den Rechner klaut hat im besten Fall einmalig die aktuellen Daten.
Ein Angreifer der sich auf welchem Weg auch immer dauerhaften Zugriff zum weiterhin genutzten System verschafft, kriegt bis auf Weiteres auch alle Updates.

Oder glaubst du der Dieb gibt das Notebook nach dem Diebstahl einfach zurück und tut so als sei nichts, dabei hat er aber /boot manipuliert?

Wenn es ihm wirklich um die Daten geht und nicht um den Klumpen Elektronik, dann ja. Vielleicht muss er das Gerät auch gar nicht klauen, sondern "putzt" einfach dein Büro, während du in der Kantine bist.

[cosinus]

Also ich hab @ruth so verstanden, dass niemand an ihre Daten kommen soll wenn das Notebook geklaut wird. Und da keine privaten Daten in /boot abgelegt werden, ist das Gerät nach dieser Anforderung geschützt. /boot zu verschlüsseln ist ja möglich aber auch in der von @ruth verlinkten Anleitung steht ja:

Diese Partition [boot] wird unverschlüsselt bleiben und Platz für mehrere Kernelversionen bereithalten. Das ist ein Zugeständnis, da es ansonsten noch einige weitere Hürden zu überwinden gibt (GRUB müsste den verschlüsselten Kernel laden; ggf. gelten besondere Anforderungen in Sachen EFI/UEFI). Andererseits: Wenn dir jemand einen Kernel mit integriertem Keylogger unterschiebt, ist das Kind schon an ganz anderer Stelle in den Brunnen gefallen.

Wenn boot unbedingt verschlüsselt sein muss, könnte man sich ja daran orientieren -> https://www.linux-community.de/ausgaben ... chtschutz/

Oder man setzt einfach im UEFI-Setup oder per hdparm ein Passwort für die interne SSD falls möglich.

[Tintom]

Wenn boot unbedingt verschlüsselt sein muss, könnte man sich ja daran orientieren -> https://www.linux-community.de/ausgaben ... chtschutz/

Für debian angepasst: https://cryptsetup-team.pages.debian.ne ... -boot.html, was jedoch auch schon wieder veraltet ist, da grub seit bullseye angeblich ein verschlüsseltes /boot ohne Umwege lesen kann (nicht selbst getestet).