[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: