Warum wird das Deaktivieren von "Secure Boot" bei der Installation von Modulen von Drittanbietern durchgesetzt?

Bei der Installation von 16.04 wurde ich aufgefordert, " Secure Boot " zu deaktivieren , wenn ich Module / Treiber von Drittanbietern installieren wollte .

Ich habe nicht befolgt.

Und als ich die einzigen von mir verwendeten Treiber von Drittanbietern ( bcmwl-kernel-source ) manuell installierte , wurde ich (während der Installation des Pakets) erneut aufgefordert, "Secure Boot" zu deaktivieren .

Die Verwendung von bcmwl-kernel-source war mit Secure Boot in 15.10 völlig in Ordnung . Dies scheint nicht mit einem Bug zu tun zu haben.

Das sieht also so aus, als würde Ubuntu es ablehnen, die Treiber / Module von Drittanbietern zu signieren, damit es mit "Secure Boot" funktioniert (??). Oder scheinen Module von Drittanbietern als unsicher zu betrachten und "Secure Boot" zu unterbrechen, wodurch die Deaktivierung erzwungen wird, um dies zu verdeutlichen? Habe ich recht ?

Dies ist kein Fehler, es ist eine Funktion.

Wie Anthony Wong sagt, wenn Sie ein DKMS-Paket installieren, kompilieren Sie das Paket selbst, daher kann Canonical das Modul nicht für Sie signieren.

Sie können jedoch auf jeden Fall Secure Boot verwenden. Dies ist jedoch genau der Anwendungsfall, in dem Secure Boot versucht, Sie vor sich selbst zu schützen, da es nicht wissen kann, ob Sie einem Modul vertrauen oder nicht.

Standardmäßig befindet sich auf Ihrem UEFI-Computer ein Platform Key (PK), die letztendlich vertrauenswürdige Zertifizierungsstelle zum Laden von Code in Ihren Prozessor.

GRUB, Shim oder andere Boot-Mechanismen können von einem KEK digital signiert werden, der von der Root-CA (PK) als vertrauenswürdig eingestuft wird. Auf diese Weise kann Ihr Computer ohne Konfiguration Software wie Ubuntu Live USB / DVDs booten.

Unter Ubuntu 16.04 wird der Kernel mit CONFIG_MODULE_SIG_FORCE = 1 erstellt. Dies bedeutet, dass der Kernel die Signatur von Modulen durch einen vertrauenswürdigen Schlüssel auf der Plattform erzwingt . Beachten Sie, dass die UEFI-Plattform standardmäßig eine PK enthält, über die Sie keine Kontrolle haben, und Sie daher keine Binärdateien mit einem von Ihrem eigenen Computer erkannten Schlüssel signieren können.

Einige Leute schimpfen und schimpfen dagegen, aber es gibt wirklich keinen besseren Weg (vom Standpunkt der Sicherheit aus) als Sie selbst, der den gewünschten neuen Schlüssel einschreibt.

Wenn Ihr Boot-System Shim verwendet, können Sie eine sogenannte Datenbank für Maschinenschlüssel verwenden und Ihren Schlüssel als MOK registrieren (Sie können dies mit mokutil tun). Andernfalls können Sie Ihren Schlüssel auch als Signaturschlüssel in der UEFI-Datenbank registrieren .

Nachdem Sie Ihren Schlüssel registriert haben, können Sie Ihr von DKMS erstelltes Paket mit Ihrem MOK signieren (es sollte ein Perl-Skript unter vorhanden sein /usr/src/kernels/$(uname -r)/scripts/sign-file), und nachdem es signiert wurde, können Sie es in den Kernel laden .

Zugegeben, jemand sollte mehr visuelle Anweisungen dazu geben und wahrscheinlich sogar einen Assistenten oder einen besseren DKMS-Standard erstellen, um die Berücksichtigung von Schlüsseln zu ermöglichen, aber das ist, was wir ab sofort haben.

In dieser Erklärung erfahren Sie, wie Sie Ihre eigenen Kernel-Module signieren: https://askubuntu.com/a/768310/12049

Kurz gesagt, dies ist kein Fehler, sondern eine neue Änderung, die im 16.04 eingeführt wurde.

Denn was Sie installieren, ist ein dkms-Paket. DKMS-Module werden auf Ihrem eigenen Computer kompiliert, sodass Canonical das Modul nicht für Sie signieren kann. Wenn Canonical es nicht signieren kann, kann es nicht digital überprüft werden. Wenn Sie den sicheren Start aktiviert haben, bedeutet dies, dass Ihr Modul nicht verwendet werden kann. Um es zu verwenden, müssen Sie den sicheren Start deaktivieren. Aus diesem Grund werden Sie von der Frage gefragt.

Rod Smith hat eine gute Antwort gegeben, warum es nur in 16.04, nicht aber in früheren Releases passiert. In Ubuntu 16.04 beginnt Ubuntu, einen sicheren Start auf Kernel-Ebene zu erzwingen. Vor 16.04 zwingt Ubuntu Sie nicht wirklich dazu, signierten Kernel und signierte Kernel-Module zu verwenden, selbst wenn Sie den sicheren Start aktiviert haben. Dies ist aber im 16.04 nicht mehr der Fall.

Dies ist der verwandte Fehler: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532

Dies ist der zugehörige Entwurf: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-installing-unsigned-secureboot

Eine andere Möglichkeit besteht darin, einen eigenen Schlüssel zu erstellen, den öffentlichen Teil in die MOK-Datenbank einzufügen und die von Ihnen kompilierten Module mit dem privaten Teil zu signieren. Detaillierte Informationen finden Sie hier: 'vboxdrv' konnte nach dem Upgrade auf Ubuntu 16.04 nicht geladen werden (und ich möchte den sicheren Start beibehalten)

Die akzeptierte Antwort ist sehr vollständig, aber ich möchte diese einfache Information hinzufügen, die von hier stammt:

https://askubuntu.com/a/843678/664391

Grundsätzlich kann ein sicherer Start verhindern, dass Sie einen von Ihnen installierten Treiber laden, was sehr frustrierend sein kann. Ich habe das selbst durchgemacht: Der Treiber wurde korrekt installiert, alles schien in Ordnung zu sein, aber es hat einfach nicht funktioniert. Es hat einige Zeit gedauert, bis ich herausgefunden habe, dass es sich um einen sicheren Start handelt , der das Laden des Betriebssystems verhindert.