UEFI Secure Boot => Kernel Lockdown => kein Tiefschlaf. Warum?
Hi!
Das Experiment ist bereits wieder beendet. Es macht ohnehin keinen Sinn…
aber… was ich versuchte war: Nachdem ich jetzt alles außer /boot mit
LUKS verschlüsselte, aktivierte ich UEFI Secure Boot und setzte ein
Supervisor-Password im ThinkPad-BIOS. Die Idee dahinter war, es ein
wenig schwieriger zu machen, dass jemand mit physikalischem Zugriff auf
das Laptop in den Bootvorgang etwas einschleusen kann.
Dummerweise triggerte Secure Boot die Kernel Lockdown-Funktion (ab
Kernel 5.4). Und damit fiel dann der Tiefschlaf wegen weg, denn so die
krude Argumentation: root könnte ja das Tiefschlaf-Image in Swap
manipulieren.
Da komme ich wieder an den Punkt: Ich verstehe es nicht! Nullkomma gar
nicht. Das Swap-Laufwerk ist verschlüsselt… und falls jemand Zugriff auf
die Root-Rechte des Systems bekommt, dann kann es mir doch auch
komplett, total und vollkommen egal sein, inwiefern er auch noch den
Kernel manipulieren kann?
Was übersehe ich da?
Jetzt habe ich UEFI Secure Boot wieder ausgeschaltet, womit jemand jetzt
in den Kernel was einschleusen kann.
Ähnliches gilt für signierte Kernel und Kernel-Module. Wenn jemand Root-
Rechte auf meinem System hat, warum soll es mich dann noch
interessieren, wenn er irgendwelche Kernel-Module laden kann, die nicht
signiert sind?
Was ich als begrenzt sinnvoll ansehe, den Boot-Vorgang *bis* zum
Entschlüsseln des LVM mit / und Swap abzusichern, damit das niemand
manipuliert. Aber danach? Wieso danach? Aus meiner Sicht ist das für
einen Otto-Normal-Verbraucher absolut, vollkommen und total sinnlos?
Kann ich das machen? Kann ich mit einem Debian-Kernel diesen ganzen
Lockdown-Kram einfach ausschalten, auch wenn UEFI Secure Boot aktiv ist.
Oder muss ich dafür wirklich meinen eigenen Kernel konfigurieren?
Natürlich kann ich tp-smapi dann auch mit Modul-Schlüssel einrichten,
aber ganz ehrlich… wozu?
Ich würde also an sich gerne mit shim und GRUB und Kernel noch alles
signieren… danach ist es mir aber pille palle egal, denn sobald jemand
das LUKS-Passwort zum Entschlüsseln hat… kommt es auch nicht mehr darauf
an, inwiefern er irgendetwas am Kernel rumbasteln oder irgendwelche
komischen Module laden kann.
Oder die andere Möglichkeit: Ich lasse einfach alles unsigniert. Also
shim-unsigned usw. usf. – dann könnte mir jemand aber einen Trojaner in
den Boot-Vorgang einbauen. Ich tendiere dazu, das Risiko einzugehen…
UEFI Secure Boot, Kernel Lockdown usw. ist so komplex, dass ich davon
ausgehe, dass es da ohnehin immer wieder Sicherheitslücken geben wird…
d.h. falls jemand anderes länger physikalisch Zugriff auf das Laptop
bekommt, muss ich es als kompromittiert ansehen…
Wie handhabt ihr das?
Alles aus? Alles an? Oder einen Ansatz, der bis zum Freischalten der
Verschlüsselung schützt?
Mit einem Handy habe ich LineageOS mit gesperrtem Bootloader… ich
dachte, ich kann mir so etwas auch für Linux bauen… aber sobald jemand
entweder Root-Rechte bekommt, während das System läuft, oder aber das
LUKS-Passwort herausfindet… ist es ohnehin zu spät. Daher sehe ich
zusätzlichen Schutz, den Kernel nach Booten des Linux-Systems vor "root"
abzusichern, als reichlich sinnfrei an. Gegen was für Angriffe soll das
helfen? Das hilft nicht mal gegen Evil Maid-Angriffe oder übersehe ich da
etwas? Wenn jemand Root-Zugriff hat, der den nicht haben sollte, ist es
zu spät. Ende Gelände.
Ciao,
--
Martin
Reply to: