Mit Secure Boot unsignierte DKMS Module laden [unmöglich]

[nudgegoonies]

Wie schalte ich es ab, dass der Kernel nur signierte Module lädt? Ich brauche die Module für Virtualbox für Virtualisierung und dann auch noch bbswitch, um die diskrete NVIDIA GPU komplett abzuschalten.

[towo]

Wie schalte ich es ab, dass der Kernel nur signierte Module lädt?

Indem Du secureboot deaktivierst?
Oder indem Du deine Module mit einem gültigen Schlüssel signierst?

[nudgegoonies]

Ich will nichts von beidem. Ist schon lange her, dass ich über Secure Boot in Debian gelesen habe. Aber ich dachte es sei so, dass nur der SHIM von Microsoft signiert ist und der SHIM dann die Debian Signatur des Kernels überprüft. Aber warum Module blockieren? Wenn man root-Rechte hat ist, und das haben die meisten, kann man doch sowieso beliebig im Speicher schreiben. Also ein Modul auch anders in den Speicher bringen. Es muss doch einen Weg geben die Modul-Signatur-Überprüfung auszuschalten um Treiber nachzuladen. Wenn das nicht möglich ist, hat das ganze ja überhaupt keinen Sinn und man muss für Linux immer noch grundsätzlich Secure Boot abschalten bei all den DKMS Modulen die man im Alltag so braucht.

[bluestar]

Ich will nichts von beidem.

Dir wurden zwei Lösungsansätze genannt, hier Variante 3:

Du passt einfach den Kernel-Quellcode nach deinen Wünschen an, kompilierst, signierst und installierst deinen eigenen Kernel und wirst glücklich.

[towo]

Wenn ich das alles so lese, frage ich mich echt, wozu Du Secureboot aktiviert hast. Das macht bei Deinen Äüßerungen NULL Sinn.

[nudgegoonies]

Kurz gefasst. Ich musste Secure Boot eh abschalten lassen, da Suspend to Disk wie im Debian Wiki beschrieben nicht funktioniert. Und für mich ist das ein Killerfeature. Und nach allem was ich sonst noch im Debian Wiki dazu gelesen habe ist es für mich unbrauchbar, auch wenn man selber Module signieren kann. Wobei sowas bei von Debian gelieferten DKMS Modulen auch automatisch passieren sollte.

Ich drücke mich anders aus. So etwas ähnliches wie (!) Secure Boot würde meiner Meinung nach dahingehend Sinn machen, dass auf einen Laptop mit verschlüsselter Platte niemand im unverschlüsselten Teil (also in der Boot Partition) einen Keylogger installieren kann. Aber sobald ich mein mein Passwort für die Verschlüsslung eingegeben habe möchte ich alles machen können. Sowas wie Kernel-Lockdown im Zusammenhang mit Secure Boot ist meiner Meinung nach Schwachsinn. Das bringt auch keine Sicherheit, denn es schützt nicht vor Keyloggern im Userspace.

[DeletedUserReAsG]

Natürlich: wenn du für dich kein Anwendungsszenario siehst, ist das mal per se Schwachsinn. Für jeden und ganz allgemein.

… ’n bisschen frag ich mich schon, was mit den Menschen derzeit los ist. Jeder hält sich für den Mittelpunkt des Universums, und scheint gar nicht verstehen zu können, dass es noch andere Menschen gibt, die andere, von den eigenen abweichende, Ansprüche haben könnten. Konfigurier’s dir, wie du es haben willst, aber erzähl anderen nicht, was für sie sinnvoll ist, und was nicht.

[nudgegoonies]

Du willst, dass man vor jeder Meinungsäußerung ein "Meiner Meinung nach ist das..." schreibt statt "Das ist..."? Wenn Dir das so wichtig ist, dass Du nur deswegen hier schreibst editiere ich das sogar extra für Dich!

Meiner Meinung nach sollte Secure Boot genau das tun, was der Name verspricht. Den Bootprozess absichern. Kernel Lockdown, egal ob für jemanden sinvoll oder nicht, hat damit aber wirklich überhaupt nichts zu tun!

P.S.
Gerade gefunden bei Golem: https://www.golem.de/news/secure-boot-l ... 33670.html Zitat Linus Torvalds:

Der Linux-Chefentwickler führt seine Kritik weiter aus und schreibt, dass zwar der Lockdown im Allgemeinen vielleicht eine gute Sache sei, dies aber eben nichts mit Secure Boot zu tun habe. Die zwei Techniken passten schlicht nicht zueinander und hätten keine Überschneidungen, schreibt Torvalds.

[Blue]

@nudgegoonies:
Ich stimme den Posts von "niemand, bluestar und towo" zu. Es ist irgendwie unklar, was Du willst.

Mit Secure Boot unsignierte DKMS Module laden [unmöglich]

> Klar, das ist per Definition so.
Du könntest genau so sagen: "Schreiben mit einem Kuli ohne Tintenpatrone geht nicht".

Du kannst Dir "Secure-Boot" wie es deiner Meinung nach sein sollte vorstellen oder es so verstehen, wie es eben in realiter ist.
Ich persönlich nutze Zeugs wie Fast-Boot oder Secure-Boot nicht, weil sie meiner Meinung nach Mumpitz sind. Daher deaktiviere ich sie im UEFI-Bios.
Das UEFI macht immerhin Sinn, wegen der GPT-Partitionierung.

[nudgegoonies]

Wie weiter oben schon beschrieben. Ich möchte einen sicheren Boot-Prozess. Dass keiner auf der unverschlüsselten Boot-Partition einen Keylogger zum Abfangen des Festplattenverschlüsselungspassworts einbinden kann. Sobald das System von der verschlüsselten Platte gebootet hat, will ich das System ohne die Einschränkungen des Kernel-Lockdown nutzen (Hibernate, unsignierte Module, etc.).

So wie ich Linux Torvalds Kommentar verstehe, ist der Kernel-Lockdown eine Anforderung von Microsoft, damit sie Shim oder den Kernel signieren. Darum wird bei Secure Boot, so wie Microsoft es will, das signierte Booten mit einer völlig anderer Sicherheitstechnologie, dem Kernel-Lockdown, verknüpft. Weil ich das eine will und das andere nicht, muss ich Secure Boot ausschalten. Damit ist die Festplattenverschlüsselung mit LUKS und LVM sinnlos.

Kernel-Lockdown klingt für mich nur für Server interessant. Für einen normalen Anwender, wo es nur einen Benutzer auf dem Laptop gibt der sudo hat, ist Schutz für den Userspace viel wichtiger. Sobald z.B. ein Verschlüsselungs-Trojaner im Userspace ist, hat man verloren. Der Trojaner braucht, um Schaden anzurichten weder einen local root expoit und erst recht kein Kernelmodul laden.

[Blue]

@nudgegoonies:

So wie ich Linux Torvalds Kommentar verstehe, ist der Kernel-Lockdown eine Anforderung von Microsoft, damit sie Shim oder den Kernel signieren.

So sehe ich das auch.
Und es ist "erstaunlich", welche "Gestaltungskraft" ein Betriebssystementwickler auf die Gesamtheit der Hardwarehersteller hat...
Und es gibt Stimmen, welche behaupten, dass das Einsatzziel von Secure-Boot vielgestaliger sein könnte, als man denkt...
Dass irgend ein Prozeß das Betriebssystem schon im Bios beeinflußen kann, halte ich selbst kaum für "secure".

[nudgegoonies]

"Gestaltungskraft" ist bei dem Thema ein sehr guter Euphemismus

Bezüglich BIOS finde ich es schade, dass sich an der Front der alternativen BIOSe wie CoreBoot so wenig tut was Consumer-Hardware betrifft. Daraum weiß ich gar nicht, ob die so etwas wie einen "Signature-Boot" Mechanismus überhaupt mitbringen.

[bluestar]

Wie weiter oben schon beschrieben. Ich möchte einen sicheren Boot-Prozess. Dass keiner auf der unverschlüsselten Boot-Partition einen Keylogger zum Abfangen des Festplattenverschlüsselungspassworts einbinden kann.

Dann würde ich an deiner Stelle erst einmal mit Secure Boot tiefer einsteigen und einen MOK (Machine Owner Key) erzeugen und im BIOS installieren, damit auch wirklich nur DU derjenige bist, der Signaturen ausstellen kann.

Was nützt dir Secure-Boot, wenn für dich nicht klar nachvollziehbar/belegbar ist, wer das Recht hat Software für deinen Boot-Prozess zu signieren?

[bluestar]

Wie weiter oben schon beschrieben. Ich möchte einen sicheren Boot-Prozess. Dass keiner auf der unverschlüsselten Boot-Partition einen Keylogger zum Abfangen des Festplattenverschlüsselungspassworts einbinden kann.

Dann würde ich an deiner Stelle erst einmal mit Secure Boot tiefer einsteigen und einen MOK (Machine Owner Key) erzeugen und im BIOS installieren, damit auch wirklich nur DU derjenige bist, der Signaturen ausstellen kann.

Was nützt dir Secure-Boot, wenn für dich nicht klar nachvollziehbar/belegbar ist, wer das Recht hat Software für deinen Boot-Prozess zu signieren?

[Blue]

@nudgegoonies:

...ein sehr guter Euphemismus.

Thx.
Ich baue darauf, dass wie Du, der Leser mitdenkt. Den Mainstream-Casual-PC-User erreicht man in der Regel mit kritischen Posts sowieso nicht.
Interessant wäre die Frage: "Alexa, was hat es mit Secure-Boot auf sich?"

@bluestar:

...nicht klar nachvollziehbar/belegbar ist, wer das Recht hat Software für deinen Boot-Prozess zu signieren?

Das meinte ich mit:

Und es gibt Stimmen, welche behaupten, dass das Einsatzziel von Secure-Boot vielgestaliger sein könnte, als man denkt...

Allerdings befürchte ich, dass es mit dem Deaktivieren von Secure-Boot nicht getan ist. Das Bios könnte mit dem "neuen" UEFI nach wie vor "zugänglich" sein.

[DeletedUserReAsG]

Das Bios könnte mit dem "neuen" UEFI nach wie vor "zugänglich" sein.

Es gibt Management Engines und ähnlichen Kram, der quasi neben dem eigentlichen OS läuft. Mit UEFI oder Secureboot hat’s aber erstmal nicht direkt etwas zu tun.

[Blue]

@niemand:
Schon klar - Aber:
In einem Thread hier (ich weiß den Link nicht mehr) war jemand zum Beispiel zurecht darüber erstaunt, dass man mit UEFI aus Windows heraus das Bios updaten kann. Das heißt aus meiner bescheidenen laienhaften Sicht, dass man aus dem Betriebssystem heraus auf das Bios zugreifen kann. Und das halte ich nicht für "secure" sondern für "vulnerable". Es kann aber natürlich sein, dass ich mich irre. Es wäre nicht das erste Mal.

[DeletedUserReAsG]

In einem Thread hier (ich weiß den Link nicht mehr) war jemand zum Beispiel zurecht darüber erstaunt, dass man mit UEFI aus Windows heraus das Bios updaten kann.

Eigentlich war’s aber schon immer™ so, dass zum Update des BIOS oder UEFI ein OS gestartet werden muss. Gerne wurde ein dediziertes DOS genommen, weil’s kein Multitasking hat, und daher keine anderen Prozesse den recht sensiblen Update-Prozess stören können, aber genausogut ging’s in der Regel direkt von Windows aus (wenngleich manche Hersteller drauf bestanden haben, dass ein reines DOS gebootet wird – aus o.g. Grund).

Die Möglichkeit, das Update direkt vom UEFI-/BIOS-Menü direkt aus zu fahren, ist erst viel später gekommen, und noch gar nicht soo alt.

[debianuser4782]

@niemand:
Schon klar - Aber:
In einem Thread hier (ich weiß den Link nicht mehr) war jemand zum Beispiel zurecht darüber erstaunt, dass man mit UEFI aus Windows heraus das Bios updaten kann. Das heißt aus meiner bescheidenen laienhaften Sicht, dass man aus dem Betriebssystem heraus auf das Bios zugreifen kann. Und das halte ich nicht für "secure" sondern für "vulnerable". Es kann aber natürlich sein, dass ich mich irre. Es wäre nicht das erste Mal.

Ja, ein Angriff auf den BIOS aus einem OS heraus ist möglich. Es gibt da auch einige Artikel bei heise.de und golem.de dazu.
Könnte man einen infizierten oder kompromittierten BIOS über ein Update desselben über seine eigene Update-Funktion eigentlich wieder "heilen"?
Und ist die Installation einer minimalen Linux-Distribution (ggf mit selbst kompilierten minimalen Kernel) genauso anfällig für diesbezügliche Angriffe wie Windows 10? Wenn nein, wäre es wohl besser niemals Windows auf einem Rechner zu installieren, wenn man ganz sicher gehen möchte. Dasselbe gilt wohl auch für übrige Firmware, die nicht zum BIOS gehört.

[nudgegoonies]

Dann würde ich an deiner Stelle erst einmal mit Secure Boot tiefer einsteigen und einen MOK (Machine Owner Key) erzeugen und im BIOS installieren, damit auch wirklich nur DU derjenige bist, der Signaturen ausstellen kann.

Was nützt dir Secure-Boot, wenn für dich nicht klar nachvollziehbar/belegbar ist, wer das Recht hat Software für deinen Boot-Prozess zu signieren?

Das werde ich sicher mal ausprobieren ob ich damit signiert booten kann ohne den Kernel-Lockdown. Aber erst sobald ich privat auch einen UEFI-BIOS Laptop habe. Auf meinem Firmenrechner ist das BIOS für mich leider tabu.

[nudgegoonies]

In einem Thread hier (ich weiß den Link nicht mehr) war jemand zum Beispiel zurecht darüber erstaunt, dass man mit UEFI aus Windows heraus das Bios updaten kann. Das heißt aus meiner bescheidenen laienhaften Sicht, dass man aus dem Betriebssystem heraus auf das Bios zugreifen kann. Und das halte ich nicht für "secure" sondern für "vulnerable". Es kann aber natürlich sein, dass ich mich irre. Es wäre nicht das erste Mal.

Die Frage ist, passiert das wirklich aus Windows heraus? Oder ist das wie bei fwpdate unter Linux, dass da einmalig der Updater auf die UEFI Partition kommt, danach durch einen Neustart in diesen Updater gebooted wird, und nach dem nächsten BOOT-Vorgang wieder weggeputzt wird. Was aber bedeutet, dass diese Firmware-Updater ja auch wieder signiert sein müssen.