Nachdem ich vor Kurzem einen Treiber installiert hatte, bei dem das Modul manuell signiert werden musste, war ich verwirrt, was die Signierung dieses Moduls eigentlich bewirkte und warum sie durchgeführt werden musste.
Es gibt hier noch weitere Fragen zum Vorgang, die sind jedoch eher technischer Natur. Was ist eine einfache Erklärung dafür, was das Signieren von Modulen bewirkt und warum es notwendig ist, sowie welche Alternativen es gibt (anscheinend kann DKMS Module automatisch signieren)?
Antwort1
Der Kernel kann so konfiguriert werden, dass er Sie entweder nur warnt, wenn nicht signierte oder falsch signierte Module verwendet werden (durch eine Protokollnachricht + durch Setzen eines Taint-Flags im Kernel) oder alle Kernelmodule, die keine Signatur haben, die der Kernel validieren kann, direkt ablehnt.
Bei Verwendung eines BIOS-ähnlichen Bootvorgangs oder bei Verwendung von UEFI mit deaktiviertem Secure Boot handelt es sich im Wesentlichen nur um ein optionales zusätzliches Sicherheitsverfahren. Es wird Eindringlingen etwas schwerer gemacht, bösartige Kernelmodule (wie kernelbasierte Rootkits, um die Tools und Aktionen des Eindringlings zu verbergen) in das System einzuschleusen.
Wenn Sie UEFI jedoch mit aktiviertem Secure Boot verwenden, ist dies Teil der Secure Boot-Anforderungen. Der „Geist“ von Secure Boot besteht darin, das Laden von nicht vertrauenswürdigem Code in den Kernelspeicher zu verhindern. Die UEFI-Firmware prüft, ob im Bootloader eine gültige Signatur (oder ein auf der Whitelist stehender SHA256-Hash) vorhanden ist. Der Bootloader muss im Betriebssystemkernel nach derselben Signatur suchen. Und der Kernel muss diese Anforderung auf allen Code ausweiten, der im Kernelspeicher ausgeführt werden soll.
In der Praxis kann der Betriebssystemkernel diese Anforderung natürlich problemlos ablehnen. Die Organisationen, die Secure Boot entwickelt haben, haben jedoch entschieden, dass diese Ablehnung zumindest eine bestimmte Aktion des Systemadministrators erfordern sollte: Die Standardeinstellung sollte die Durchsetzung der Signaturanforderung sein.
(Das ist übrigens auch einer der Gründe, warum moderne Windows-Betriebssysteme standardmäßig verlangen, dass alle installierten Treiber signiert sind. Wenn Sie nicht signierte Treiber installieren möchten, müssen Sie explizit eine Einstellung ändern, die Administratorzugriff erfordert.)
Ein Tool, das auf einem Secure Boot-System bootfähig wäre und die Ausführung von unsigniertem Kernel-Space-Code "out of the box" ermöglichen würde, wäre einGerät zur Umgehung des sicheren Startvorgangsund wäre als Schadsoftware einzustufen.
Microsoft ist der bekannteste Secure Boot-Signator und signiert nur Versionen des shimx64.efiShim-Bootloaders, die die Signaturanforderung erzwingen.
Eine Secure Boot-fähige UEFI-Firmware verfügt über eine integrierte Funktion zum Überprüfen von Signaturen bei Binärdateien, die das Microsoft PE+-Binärformat verwenden, das die *.efiDateien verwenden. In der Linux-Welt wird dieses Binärformat jedoch im Allgemeinen nicht verwendet: Stattdessen wird das ELF-Binärformat verwendet.
Sowohl Linux-Kernelmodule als auch GNU GRUB-Bootloadermodule basieren auf dem ELF-Format. Dies erfordert, dass Bootloader und Kernel eigene Signaturprüfalgorithmen für ELF-Binärdateien bereitstellen, aber anscheinend hat das UEFI-Forum (das Industriekonsortium, das die UEFI- und Secure Boot-Spezifikationen verwaltet) entschieden, dass dies in Ordnung ist, solange die Standardanforderung für gültige Signaturen beibehalten wird.
Natürlich funktioniert das nicht ganz wie erwartet, wenn Sie DKMS zum automatischen Erstellen und Signieren von Kernelmodulen verwenden: Es bedeutet, dass ein Zertifikat mit seinem privaten Schlüssel vorhanden ist, mit dem automatisch eine gültige Signatur erstellt werden kann, sodass ein Eindringling es auch zum Signieren bösartiger Kernelmodule verwenden kann. Das ist nicht weniger sicher als ein System ohne Secure Boot, aber auch nicht viel sicherer.
Wenn Sie mehrere Systeme haben, können Sie einen gewissen Sicherheitsvorteil erzielen, wenn Sie den privaten Schlüssel für Ihr Modulsignaturzertifikat nur auf einem Host haben (vermutlich dem, der am wenigsten von Angreifern bedroht ist) und diesen zum Erstellen aller benutzerdefinierten Kernel und/oder Module verwenden, die Sie möglicherweise benötigen, und diese von dort aus an alle anderen Hosts verteilen, die sie benötigen. Auf diese Weise würden die anderen Hosts nur den öffentlichen Teil des Modulsignaturzertifikats benötigen, der nur zum Validieren vorhandener Signaturen verwendet werden kann, nicht zum Erstellen neuer Signaturen.