Secure Boot unter diversen Betriebssystemen

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:
Da ich plane, mir sehr bald einen neuen PC zuzulegen, habe ich mich natürlich auch mit der Secure Boot Frage im Bezug auf FreeBSD auseinandergesetzt. Ich werde definitiv ein Mainboard beim Händler meines Vertrauens bestellen, bei dem sich Secure Boot im BIOS abschalten lässt, denn offenbar...
Yamagi schrieb:
Für FreeBSD ist Secure Boot im Kommen, es wird wahrscheinlich in 13.0 dabei sei.
Zum Vergrößern anklicken....
Ja? Also, bei 13.2 war es definitiv noch nicht dabei und in den Release-Notes zu 14.0 war auch noch nirgenwo davon die Rede.
https://wiki.freebsd.org/SecureBoot
Diese Information ist laut Google jedoch vom 13.07.2021, also nicht mehr wirklich aktuell. Weiß jemand, ob in der Hinsicht überhaupt noch was geplant ist, oder hat man die Unterstützung für Secure Boot bei FreeBSD mittlerweile ad acta gelegt?
 
Macke1979 schrieb:
Da ich plane, mir sehr bald einen neuen PC zuzulegen, habe ich mich natürlich auch mit der Secure Boot Frage im Bezug auf FreeBSD auseinandergesetzt. Ich werde ein Mainboard beim Händler meines Vertrauens bestellen, bei den sich Secure Boot abschalten lässt, denn offenbar...

Ja? Also, bei 13.2 war es definitiv noch nicht dabei und in den Release-Notes zu 14.0 war auch noch nirgenwo davon die Rede.
https://wiki.freebsd.org/SecureBoot
Diese Information ist laut Google jedoch vom 13.07.2021, also nicht mehr wirklich aktuell. Weiß jemand, ob in der Hinsicht überhaupt noch was geplant ist, oder hat man die Unterstützung für Secure Boot bei FreeBSD mittlerweile ad acta gelegt?
Zum Vergrößern anklicken....

Ich weiß das du es nicht so gemeint hast, aber es klingt in diesen Posts immer so als müsste man irgend ein speziellen PC mit abschaltbaren Secure-Boot kaufen, weil 90% das nicht mehr abschaltbar haben.

Das ist nicht so - eine überwältigende Mehrheit mit "default on" hat einen simplen abschaltknopf im UEFI - ich würde "gefühlt" sagen weit über 90%.

(Nur als Info weil ich es unglücklich finde wenn etwas so steht)
 
CommanderZed schrieb:
Ich weiß das du es nicht so gemeint hast, aber es klingt in diesen Posts immer so als müsste man irgend ein speziellen PC mit abschaltbaren Secure-Boot kaufen, weil 90% das nicht mehr abschaltbar haben.
Zum Vergrößern anklicken....
Ehrlich gesagt bin ich da nicht sooo auf dem allerneuesten Stand, da mein Haupt-PC aus dem Jahr 2016 und mein Laptop (auf dem ich es ebenfalls abschalten konnte und dementsprechend auch dort FreeBSD draufgepackt habe) auch schon mehr als 2 Jahre auf dem Buckel hat. Da jedoch Windows 11 Secure Boot und TPM 2.0 unbedingt erfordert, frage ich mich schon, ob es nicht irgendwann Boards ausschließlich geben wird, bei denen man Secure Boot nicht abschalten kann. Und deshalb frage ich mich auch, ob man die Secure Boot Pläne für FreeBSD inzwischen fallengelassen hat. ;)
 
Macke1979 schrieb:
Ehrlich gesagt bin ich da nicht sooo auf dem allerneuesten Stand, da mein Haupt-PC aus dem Jahr 2016 und mein Laptop (auf dem ich es ebenfalls abschalten konnte und dementsprechend auch dort FreeBSD draufgepackt habe) auch schon mehr als 2 Jahre auf dem Buckel hat. Da jedoch Windows 11 Secure Boot und TPM 2.0 unbedingt erfordert, frage ich mich schon, ob es nicht irgendwann Boards ausschließlich geben wird, bei denen man Secure Boot nicht abschalten kann. Und deshalb frage ich mich auch, ob man die Secure Boot Pläne für FreeBSD inzwischen fallengelassen hat. ;)
Zum Vergrößern anklicken....

Ja das stimmt und ich fänd es villeicht nicht komplett sinnlos wenn bei *BSD das Thema aufgegriffen wird ... und auch in der Linux-Welt wird das Thema ja nur sehr mäßig beleuchtet.

Allerdings: Man kann Windows 11 auch ohne Secure Boot, TPM und ner aktuellen CPU verwenden - es wird dann nur nicht offiziell supportet und MS behauptet es gibt ein Risiko das es ein Update in Ferner zukunft geben könnte das dann möglichweise nicht mehr rund läuft oder irgendwas - nach 2 Jahren ist das aber noch nicht passiert. Ich habe z.B. ein altes Thinkpad X61 (Core2Duo) mit Windows 11 als kleines "erstmals nen paar Klicks versuchen" - und so grundsätzlich funktioniert alles - wenn natürlich auch nicht "Ratten Schnell"
 
in den letzten Jahren hatte ich zwei oder drei Laptops vor mir (oder in der Ferne), die dermaßen vernarrt in ihr installiertes Windows waren, dass sie rein gar nichts anderes booten wollten. Das lag nicht mal am Secure-Boot (siehe entsprechende Information zu Knoppix, was sich womöglich mit dem entsprechenden Tool ja auch für andere Systeme nutzen lässt).

Alle PCs die ich in den letzten Jahren hatte und auch teilweise neu kaufte, konnten immer SecureBoot abschalten und ich konnte auch immer FreeBSD darauf installieren. Zuletzt kümmerte ich mich gar nicht um diese Frage, als ich meinen derzeitigen PC bestellte.

Also Knoppix ist ja OpenSource (ich glaube allerdings inzwischen abgestorben) und Klaus Knopper benutzt da irgendeinen gültigen Code von irgendwoher, um dem PC sein System anständig zu melden. Das muss nur einmalig gemacht werden und deshalb denke ich, dass man so etwas auch generell benutzen können sollte, wenn man sich da mal schlau macht. Aber: Glauben =! Wissen, ich habe es selbst ja noch nie gebraucht und deshalb nie genauer angesehen.
 
Mir ist weder beruflich noch privat jemals ein standard IBM PC (also nicht sowas wie Chromebook / Apple / MS Tablet) untergekommen, bei dem man secure boot nicht im BIOS oder per jumper deaktivieren konnte. Nur der Vollständigkeit halber.
Ich selbst nutze es auch immer und hatte damit noch keine Probleme (Linux/Windows/Multiboot).
 
FreeBSD unterstützt Secure Boot seit 13.0. Das Tool zum Signieren des Loader-Binaries ist uefisign. Damit das sinnvoll ist, muss allerdings nicht nur der Loader signiert werden, sondern alles, was nicht verschlüsselt abgelegt werden kann. Dafür braucht es eine RAM-Disk, die in das Loader-Binary integriert wird. Der Prozess ist hier beschrieben: https://freebsdfoundation.org/freebsd-uefi-secure-boot/

Wenn es unbedingt Microsofts Keys sein sollen, ist der eleganteste Weg das Loader-Binary wie in dem Link beschrieben zu bauen, allerdings kein Key Enrollment in die Firmware zu machen. Stattdessen mit dem eigenen Key unterschreiben und den öffentlichen Schlüssel an einen von Microsoft signierten Shim zu binden, der damit das eigene Loader-Binary prüft. Als ich es das letzte Mal gemacht habe, habe ich https://launchpad.net/ubuntu/+source/shim-signed genommen.

Aber im Ernst, wenn ich schon aus irgendwelchen Gründen meinen Loader signiert haben will, würde ich Microsoft aus dem Spiel lassen und ein Key Enrollment in die Firmware machen. Das ist weniger Aufwand und weniger Gefrickel.
 
Yamagi schrieb:
Der Prozess ist hier beschrieben: https://freebsdfoundation.org/freebsd-uefi-secure-boot/
Zum Vergrößern anklicken....
Nun ja, aber ich glaube kaum, dass ich damit den Bootloader auf dem USB-Stick signieren kann, von dem ich mein System installieren würde, oder? Ich bezweifle, dass ein schreibender Zugriff auf das Dateisystem des Installationsmediums so einfach möglich ist. So gesehen wäre es also dennoch nicht möglich, FreeBSD mit aktiviertem Secure Boot zu installieren, da ich bsdinstall gar nicht erst starten könnte und die im Link beschriebene Anleitung zur nachträglichen Aktivierung von Secure Boot gedacht ist. Oder, habe ich da was falsch verstanden?
 
Zuletzt bearbeitet:
Nein, das stimmt schon. Klugscheißerisch gesagt könnte man sich natürlich ein eigenes Installationsmedium bauen, aber das ist nun wirklich krank :)
 
Yamagi schrieb:
Nein, das stimmt schon. Klugscheißerisch gesagt könnte man sich natürlich ein eigenes Installationsmedium bauen, aber das ist nun wirklich krank :)
Zum Vergrößern anklicken....
Dann verstehe ich aber ehrlich gesagt nicht so ganz, was das für einen Sinn macht. Wenn FreeBSD seit Version 13.0 Secure Boot unterstützt, warum bietet man dann nicht einfach auf dem Installationsmedium einen signierten Bootloader an? Ich meine... Was ist so schwer daran? Gut, noch gibt es offensichtlich auf nahezu allen Geräten die Möglichkeit, Secure Boot einfach zu deaktivieren, aber was, wenn dem eines Tages nicht mehr so ist?
 
Yamagi schrieb:
Wenn es unbedingt Microsofts Keys sein sollen, ist der eleganteste Weg das Loader-Binary wie in dem Link beschrieben zu bauen, allerdings kein Key Enrollment in die Firmware zu machen. Stattdessen mit dem eigenen Key unterschreiben und den öffentlichen Schlüssel an einen von Microsoft signierten Shim zu binden, der damit das eigene Loader-Binary prüft. Als ich es das letzte Mal gemacht habe, habe ich https://launchpad.net/ubuntu/+source/shim-signed genommen.
Zum Vergrößern anklicken....
Das verstehe ich jetzt nicht. Meines Wissens hat jede Distro ihren eigenen Shim Loader, der bereits VOR dem Signieren durch Microsoft den öffentlichen Schlüssel der Distro enthält, der dadurch mit signiert wird und mit welchem dann der zur Distro gehörende GRUB geprüft wird.

Wenn Du einen Schlüssel nachträglich an irgendeinen Shim Loader bindest, dann ist dieser doch nicht signiert und kann unbemerkt ausgetauscht werden gegen einen des Angreifers, der alle weiteren Binaries dann mit seinem Schlüssel signiert hat. Damit wäre doch die Signaturkette an der Stelle unterbrochen, oder irre ich mich da?

Wenn nicht, müsste FreeBSD doch einen eigenen Shim Loader inklusive des FreeBSD Schlüssels einmalig von Microsoft signieren lassen und diesen mitliefern, ebenso dann halt damit signierte loader.efi und Kernel Binaries.
 
SHIM hat eine eigene Liste an Zertifikaten und die kann - soweit ich weiß - nur aus dem laufenden authentifzierten System geändert werden. Ebenso gibts für diese MOK (Machine Owner Key) Liste ein Passwort - Linuxdistros setzten das gerne auf das root-Passwort, wird aber auch öfters leer gelassen. Die Bestätigung musst du immer aus der UEFI Konsole machen, du brauchst also nochmal physischen Zugriff.
 
Im Detail ist es für shim hier beschrieben: https://mjg59.dreamwidth.org/19448.html

Allerdings bleibe ich dabei, dass Secure Boot bestenfalls im Bereich von Schlangenöl befindet und schlimmstenfalls als ein DRM zu sehen ist. Es mag einige wenige Szenarien geben, wo man einen Vorteil darin sehen kann. Und wenn es nur wie bei meinem Arbeitgeber ist, dass der Auditor einen Haken auf seiner Liste machen kann. Für den absoluten Großteil der Nutzer macht es aber nur Ärger, bei einem verschwindent geringem Sicherheitsgewinn gegenüber einer vollverschlüsselten SSD. Und selbst über den kann man bei der Bröseligkeit der meisten UEFI-Implementierungen und der zum Himmel schreienden Inkompetenz im Umgang mit signierten Bootloadern noch streiten.
 
Könntest du das etwas näher ausführen? Die Verwendung von secureboot schließt eine Vollverschlüsselte SSD ja nicht aus (läuft bei mir problemlos). Da ich selbst merke, dass z.b. ein Kernelmodul nicht lädt wenn ich nicht den entsprechenden Key nachlade - und ich zum Key laden zum einen ein PW brauche, zum anderen physischen Zugang hilft es doch mal zumindest gegen alle Arten von "Angreifer hat es wie auch immer auf mein System geschafft, und will mir jetzt ein böses Kernelmodul unterjubeln".
Und auch bei einer Vollverschlüsselten SSD hab ich ja noch unverschlüsselt einen (Stage1) Bootloader. Vielleicht ist das jetzt Wunschdenken von mir, aber der sollte doch von SHIM gecheckt werden ob der Manipuliert wurde - da sonst die Signatur nicht passt.

Und da ich keine gröberen Nachteile (alle 3 Jahre mal einen Key ausrollen/tauschen) bemerke verstehe ich noch nicht was jetzt schlecht daran sein soll. Ich spreche hier natürlich nicht für Ottonormaluser, der macht sich über so etwas eh keine Gedanken sondern für einen Poweruser mit etwas technischem Knowhow.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben