Secure Boot

R

Rosendoktor

Well-Known Member
Hi alle,

nachdem ich ja nun meine erste Secure Boot fähige Maschine habe, auf der Debian, FreeBSD und Windows laufen, wollte ich es natürlich wissen... :ugly:

Okay, Debian kein großes Problem, deren Setup mit Shim funktioniert out of the box, bei Windows muss man eh nichts machen, der Krempel kommt ja von denen, und bei FreeBSD lief es darauf hinaus einen eigenen db (und dbx) Key zu erzeugen, im UEFI zu hinterlegen und den FreeBSD UEFI Loader damit zu signieren. Dann lassen sich alle drei Systeme entweder direkt oder über GRUB im Secure Boot Modus starten.

Debian und Windows führen die Validierung ja weiter über den Kernel bis zu den Modulen/Treibern, FreeBSD aber noch nicht, dessen Kernel und Module liegen aber immerhin auf verschlüsselten Partitionen die vom signierten und validierten UEFI Loader entsperrt werden.

Allerdings frage ich mich nach der ganzen Aktion, was das eigentlich bringen soll. Denn im Grunde kann ja jeder der Zugriff auf das Gerät hat, im UEFI das Secure Boot einfach abschalten und die Bootloader (und ggf Kernel/Treiber, sofern nicht verschlüsselt) beliebig manipulieren. Das UEFI ist zwar mit Passwort gesichert, aber wer weiß schon wie sicher das wirklich ist bei all den verschiedenen Geräten.

Oder hab'ich da einen Denkfehler? Gegen welche Angriffe soll Secure Boot eigentlich absichern? :confused:

Grüße,

Robert
 
Für FreeBSD ist Secure Boot im Kommen, es wird wahrscheinlich in 13.0 dabei sei. Es hat solange gedauert, da es für normale Desktops und Server weitgehend sinnlos ist und das Interesse daher lange gering war. Man kann sicher ein paar Szenarien konstruieren, in dem eine komplette Signaturkette vom UEFI bis hoch zur libc sinnvoll ist, aber wie du schon sagst, ist es in den meisten Fällen dort einfach unnützer Aufwand mit sehr überschaubaren Vorteilen. Viel interessanter ist es dann auch für geschlossene Systeme, denn man kann durch eine geschlossene Signaturkette verhindern, dass andere Software als vom Hersteller vorgesehen ausgeführt wird. Das kann man im Sinne des Kunden nutzen, bei FreeBSD ist z.B. Juniper die im Moment treibende Kraft hinter Secure Boot. Sie wollen verhindern, dass ein Angreifer die Firmware ihrer Geräte manipulieren kann. Man kann es eben auch missbrauchen, um den Kunden in einen goldenen Käfig zu sperren. Gute Beispiele sind die diversen Smartphones, deren Bootloader gesperrt ist und nicht anderes als das Hersteller-Android bootet.


Rosendoktor schrieb:
Das UEFI ist zwar mit Passwort gesichert, aber wer weiß schon wie sicher das wirklich ist bei all den verschiedenen Geräten.
Zum Vergrößern anklicken....

Tja. Das kommt drauf an. Bei normaler Konsumerhardware ist der Schutz oft überschaubar. Es gibt aber auch Fälle wie z.B. bei neueren Thinkpads, wo ein Passwort so ziemlich entgültig ist und sich (wenn man es nicht kennt) nur durch enormen Aufwand bis hin zum Überschreiben von auf dem Mainboard verlöteten Chips durch externe Hardware entfernen lässt.
 
Danke, mir ist inzwischen einiges klarer.

Ohne mich näher damit beschäftigt zu haben bin ich davon ausgegangen, dass Secure Boot vor allem gegen Offline Angriffe schützen soll, also gegen Manipulation der unverschlüsselten Bootloader (und ggf. Kernel) bei physischem Zugriff auf das Gerät. Zweifel daran hab ich dann bekommen, als ich gesehen habe, wie einfach sich Secure Boot ausschalten lässt und wie leicht sich die Keys im UEFI austauschen lassen. Alles nur geschützt durch ein windiges Passwort, welches sich wohl irgendwie auch noch mehr oder weniger einfach zurücksetzen lässt. Okay, bei Geräten die ordentlich vernagelt sind wird Secure Boot wohl diesen Zweck auch erfüllen.

Gar nicht bewusst war mir, dass auch Online Angriffe durch Malware, die sich auf Kernelebene einnisten will durch Secure Boot erschwert werden bzw. spätestens beim nächsten Start auffliegen. Scheint mir eher der wichtigere Schutz zu sein bei normalen Servern und Desktops. Schön, dass FreeBSD da dran ist und es wohl bald kommt, auch wenn ich mir da bei meinen PCs und Laptops da wenig Sorgen mache. :)

Grüße, Robert
 
*wtf* Lese gerade die Spec.

Welche SBC waeren denn empfehlenswert, mal abgesehen vom Alix Board, die noch "brauchbar" bzw. "benutzbar" sind (, d. h. Dinge die kein UEFI integrieren)?
 
mein vielleicht unsachgemäßer Senf dazu aus rein privater Sicht: wem hat es denn nicht schon mal geholfen, am installierten System vorbei ein Live-System zu starten?
Das wird zwar nicht ganz und gar unmöglich, aber der Aufwand kann schon ziemlich groß werden, wenn alles mit Passworten gesichert ist.

Im nicht privaten Umfeld verstehe ich das ganz genau so: man soll gefälligst die Dienstleistungen des Passwort-Owners kaufen, wenn ein Service notwendig wird und nicht etwa in der Lage sein, selbst Hand anzulegen, zB ein einfaches Backup-Image der installierten Platte anzulegen und bei Bedarf zurück spielen zu können.
Abseits vom Geschäftsgedanken gelten natürlich auch Sicherheitsbelange, so dass ich das durchaus verstehen kann, dass es ein Interesse an Secure Boot gibt.

Bei mir allerdings nicht.
 
Man kann sich auch mit SecureBoot ein Bootfähiges Livesystem erstellen.
Der UseCase ist - abgesehen von Kunden in goldene Käfige zu sperren wie von Yamagi erwähnt - das sichern des Systems gegen Manipulation. Die Daten sind ohnehin verschlüsselt, aber wenn ein Angreifer z.b. zugiff auf ein Notebook hat (im besten Fall wiederholt) könnte er Bootloader/Kernel manipulieren um später im Betrieb Zugriff auf die nun unverschlüsselt vorliegenden Daten zu bekommen.

Ob einem das den Aufwand wert ist soll jeder selbst entscheiden, mit Linux ist es allerdings keine große Hexerei und somit nehm ich aufs dem Notebook gerne mit.
 
Der Mehrwert von UEFI war damals, dass man die völlig kaputt BIOS-Architektur durch etwas Neueres und durchaus Besseres ersetzt hat. Der Weisheit letzter Schluss ist es aber definitiv nicht. Inzwischen hat auch Intel es eingesehen und entwickelt mit Intel SBL so eine Art Coreboot-Alternative für Embedded Systeme.

Aber insgesamt ist UEFI eben nur einer kleiner Teil des Problems. Den SMM (https://en.wikipedia.org/wiki/System_Management_Mode) gibt es seit Anfang der 1990er und erlaubt es Code neben dem Betriebssystem auszuführen. Eigentlich für Firmware gedacht, kann man darin Gott und die Welt ausführen, ohne dass das Betriebssystem es bemerkt. Es kann allenfalls indirekt durch "verlorene" Zeit auf Aktivität im SMM schließen. Seit 2008 gibt es auch noch die berüchtigte Intel Management Engine, AMD hat es irgendwann zur Bulldozer-Zeit mit dem Platform Security Processor geklont. Damit gibt es eine zweite CPU im System, die Zugriff auf alles hat. Ohne die Möglichkeit nachzuvollziehen, was die aus dieser laufende Software treibt.
 
Das Fabrikat von Intel(tm) integriert (als Firmware) ein geforktes Minix.

Edit: Das UEFI (siehe Vortrag) durch einen Linux-Kernel und go-Userland zu ersetzen mindert aber jetzt nicht wirklich die Komplexitaet. ^^
 
Zuletzt bearbeitet von einem Moderator:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben