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

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
nudgegoonies
Beiträge: 939
Registriert: 16.02.2009 09:35:10

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

Beitrag von nudgegoonies » 09.10.2019 18:18:51

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.
Zuletzt geändert von nudgegoonies am 10.10.2019 11:12:37, insgesamt 1-mal geändert.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Benutzeravatar
towo
Beiträge: 4403
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Mit Secure Boot unsignierte DKMS Module laden

Beitrag von towo » 09.10.2019 18:25:21

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
Beiträge: 939
Registriert: 16.02.2009 09:35:10

Re: Mit Secure Boot unsignierte DKMS Module laden

Beitrag von nudgegoonies » 09.10.2019 19:24:26

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.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

Re: Mit Secure Boot unsignierte DKMS Module laden

Beitrag von bluestar » 09.10.2019 19:36:32

nudgegoonies hat geschrieben: ↑ zum Beitrag ↑
09.10.2019 19:24:26
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.

Benutzeravatar
towo
Beiträge: 4403
Registriert: 27.02.2007 19:49:44
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Mit Secure Boot unsignierte DKMS Module laden

Beitrag von towo » 09.10.2019 20:01:43

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

nudgegoonies
Beiträge: 939
Registriert: 16.02.2009 09:35:10

Re: Mit Secure Boot unsignierte DKMS Module laden

Beitrag von nudgegoonies » 10.10.2019 11:12:12

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.
Zuletzt geändert von nudgegoonies am 11.10.2019 13:31:35, insgesamt 1-mal geändert.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 10.10.2019 18:39:07

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
Beiträge: 939
Registriert: 16.02.2009 09:35:10

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

Beitrag von nudgegoonies » 11.10.2019 13:30:11

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.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Benutzeravatar
rockyracoon
Beiträge: 1452
Registriert: 13.05.2016 12:42:18
Lizenz eigener Beiträge: GNU Free Documentation License

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

Beitrag von rockyracoon » 11.10.2019 18:20:59

@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
Beiträge: 939
Registriert: 16.02.2009 09:35:10

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

Beitrag von nudgegoonies » 14.10.2019 18:06:54

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.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Benutzeravatar
rockyracoon
Beiträge: 1452
Registriert: 13.05.2016 12:42:18
Lizenz eigener Beiträge: GNU Free Documentation License

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

Beitrag von rockyracoon » 14.10.2019 18:35:15

@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
Beiträge: 939
Registriert: 16.02.2009 09:35:10

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

Beitrag von nudgegoonies » 14.10.2019 21:30:00

"Gestaltungskraft" ist bei dem Thema ein sehr guter Euphemismus :THX:

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.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 15.10.2019 10:40:59

nudgegoonies hat geschrieben: ↑ zum Beitrag ↑
14.10.2019 18:06:54
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?

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 15.10.2019 10:41:02

nudgegoonies hat geschrieben: ↑ zum Beitrag ↑
14.10.2019 18:06:54
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?

Benutzeravatar
rockyracoon
Beiträge: 1452
Registriert: 13.05.2016 12:42:18
Lizenz eigener Beiträge: GNU Free Documentation License

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

Beitrag von rockyracoon » 15.10.2019 12:01:38

@nudgegoonies:
...ein sehr guter Euphemismus.
Thx. 8)
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

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

Beitrag von DeletedUserReAsG » 15.10.2019 16:43:12

rockyracoon hat geschrieben: ↑ zum Beitrag ↑
15.10.2019 12:01:38
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.

Benutzeravatar
rockyracoon
Beiträge: 1452
Registriert: 13.05.2016 12:42:18
Lizenz eigener Beiträge: GNU Free Documentation License

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

Beitrag von rockyracoon » 15.10.2019 17:20:53

@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. :roll:

DeletedUserReAsG

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

Beitrag von DeletedUserReAsG » 15.10.2019 17:26:49

rockyracoon hat geschrieben: ↑ zum Beitrag ↑
15.10.2019 17:20:53
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
Beiträge: 196
Registriert: 11.03.2018 23:09:05

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

Beitrag von debianuser4782 » 15.10.2019 23:08:44

rockyracoon hat geschrieben: ↑ zum Beitrag ↑
15.10.2019 17:20:53
@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. :roll:
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
Beiträge: 939
Registriert: 16.02.2009 09:35:10

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

Beitrag von nudgegoonies » 16.10.2019 13:10:32

bluestar hat geschrieben: ↑ zum Beitrag ↑
15.10.2019 10:40:59
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.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

nudgegoonies
Beiträge: 939
Registriert: 16.02.2009 09:35:10

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

Beitrag von nudgegoonies » 16.10.2019 13:15:22

rockyracoon hat geschrieben: ↑ zum Beitrag ↑
15.10.2019 17:20:53
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. :roll:
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.
Soft: Bullseye AMD64, MATE Desktop. Repo's: Backports, kein Proposed, eigene Backports. Grafik: Radeon R7 360 MESA.
Hardware: Thinkstation S20, Intel X58, 16GB, Xeon W3530, BCM5755 NIC, EMU10K1 SND, SATA SSD+HDS und DVD+RW.

Antworten