ubuntuusers.de

HaraldEgon schrieb:

cat /proc/sys/kernel/tainted

8192

Gibt es mit:

1

cat /proc/modules | grep -E "\((U|O)\)"

eine Ausgabe?

Inwiefern kann signieren von Rootkits vor Rootkits "schützen"?

Wenn das System kompromittiert ist, dann ist es doch schon längst zu spät. Rootkits müssen ja nicht mal unbedingt Kernelmodule sein. Klar, man kann Kernelmodule signieren, aber was nutzt ein signiertes Kernelmodul, wenn beispielsweise Systemd einen Rootkit-Dienst startet. Dann haste ein mit "Secure Boot" hoch gefahrenes System, aber kompromittiert wäre es trotzdem.

Wenn es bloß darum geht, zu überprüfen, ob irgendjemand an der initrd herumgefummelt hat, während man nicht an der Kiste gesessen hat, da gibt sehr viel es einfachere Mittel, über die man dann auch selbst die vollständige Kontrolle hat.

Zumal man ja im UEFI "Secure Boot" abschalten kann, und das sieht man dann beim booten auch nicht, ob "Secure Boot" abgeschaltet wurde.

@TE:
Du könntest

CONFIG_MODULE_SIG_FORCE=y

für den selbstgebauten Kernel aktivieren, das scsi_common.ko-Modul manuell signieren und schauen was dann beim booten passiert.

EDIT:

Waren die Module (*.ko) nach dem kompilieren, auf dem Build-System bzw. zum Zeitpunkt der Übertragung, evtl. komprimiert (*.ko.xz- oder *.ko.zst-Format)?

lubux schrieb:

cat /proc/modules | grep -E "((U|O)\)"

nichts.

CONFIG_MODULE_SIG_FORCE=y }}} für den selbstgebauten Kernel aktivieren, das scsi_common.ko-Modul manuell signieren und schauen was dann beim booten passiert.

Komischerweise werden andere Module gar nicht bemängelt.

Waren die Module (*.ko) nach dem kompilieren, auf dem Build-System bzw. zum Zeitpunkt der Übertragung, evtl. komprimiert (*.ko.xz- oder *.ko.zst-Format)?

nein

trollsportverein schrieb:

Inwiefern kann signieren von Rootkits vor Rootkits "schützen"?

Dazu kommt das man dann zwar signierte Kernelmodule hat, aber z.B. BPF und paar andere Interfaces vom Kernel munter weiter verwendet werden können um Quatsch zu machen.

Der Schutz den der ganzen Signaturbums bietet existiert primär auf geschlossenen Systemen (macOS/Android) oder aber im Bereich IoT, nicht auf einer Kiste wo jeder 0815 Dude eh sudo / Root Rechte hat die missbraucht werden können.

@encbladexp: Aber der härtste Lacher wäre dann noch, wenn es zwar mit "Secure Boot" gebootet würde, aber der Massenspeicher noch nicht mal verschlüsselt ist. 😇

trollsportverein schrieb:

@encbladexp: Aber der härtste Lacher wäre dann noch, wenn es zwar mit "Secure Boot" gebootet würde, ...

Ne, das hat der TE schon geprüft bzw. geschrieben:

sudo mokutil --list-enrolled

Secure-Boot wird nicht genutzt, ...

BTW:

:~# mokutil --list-enrolled
EFI variables are not supported on this system

cat /proc/modules | grep -E "((U|O)\)"

nichts.

Ich habe den Kernel noch mal mit der gleichen Config neugebaut, aber nur, weil ich das Zertifikat mal neu erstellt hatte. In /proc/modules werden nun alle ausser scsi_common.ko mit E gekennzeichnet.

scsi_common.ko hatte ich manuell signiert, hochgeladen und die initrd neu erzeugt, modinfo zeigt den Signatur-Block. Jetzt bemängelt er nur das Modul: virtio_ring: module verification failed: signature and/or required key missing - tainting kernel

HaraldEgon schrieb:

Jetzt bemängelt er nur das Modul: virtio_ring: module verification failed: signature and/or required key missing - tainting kernel

Und wenn du das virtio_ring manuell signierst, wird ein anderes Modul bzw. das nächste Modul bemängelt, oder?

@lubux

Du hast das Bein gebrochen, wenn du es mindestens 1x gebrochen hat, 2x ändert dann auch nicht viel: i2c_core: module verification failed: signature and/or required key missing - tainting kernel

Bitte unterlasse Fullquotes. Sie blähen den Thread nur sinnlos auf.

Lies dazu Zitate & Verhaltenskodex/Fullquote.

Da steht eindeutig:

Hier wird ausdrücklich von "Teile eines vorherigen Beitrags" gesprochen, gesamte -also komplette- Beitragen zu zitieren ist unerwünscht.

Und wenn man direkt antwortet reicht ein @[user:Benutzername:] da braucht es garkein Zitat.

Mit etwas Mogelei habe ich es geschafft:

1
2
3

make
mein Script signierte alle Module
make bindeb-pkg

Das Problem habe ich scheinbar gefunden. Mit make V=1 modules_sign kann man mehr sehen:

1

  if test -e ./debian/scripts/sign-module && ./debian/scripts/sign-module /lib/modules/5.15.199/kernel/net/netfilter/xt_statistic.ko ; then scripts/sign-file "sha512" "/usr/src/signing-key-2026.pem" certs/signing_key.x509 /lib/modules/5.15.199/kernel/net/netfilter/xt_statistic.ko  ; fi

Das klappt nicht, da ist er ja ganz falsch auf der Festplatte unterwegs...

HaraldEgon schrieb:

Das klappt nicht, da ist er ja ganz falsch auf der Festplatte unterwegs...

Evtl. mit openssl die mok-Schlüssel generieren und damit manuell signieren.

Das habe ich doch praktisch oben beschrieben.

Ich frage mich, ob make bindeb-pkg das überhaupt selbst richtig automatisch kann. Er sagt zwar x-mal SIGN module... tut's aber wohl nicht.

Abseits von eigenen Keys soll ein temporärer Key ausreichend sein: https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official "or enable signing with an ephemeral key"

Das hatte ich zwar auch schon probiert, schaue ich mir aber noch mal an.