Eigener Kernel wirklich sicherer?

[sergej2018]

Guten Morgen,

gelegentlich baue ich für Server eigene Kernel.
Meist aber nur der Treiber wegen.
Ist es eig sicherer, den Kernel selbst zu kompilieren als einen von der Stange zu nehmen?
Mir ist klar: Das Thema ist weitläufig und man kann ihn durch falsche Konfiguration sicher sehr viel unsicherer machen.
Aber mal generell gefragt: Bringt das was?

[bluestar]

Aber mal generell gefragt: Bringt das was?

Außer mehr Arbeit eigentlich ncht viel... Im schlimmsten Fall bekommst du Kernel-Sicherheitslücken erst später mit und verwendest somit länger einen angreifbaren Kernel.

[eggy]

Typischer Fall von "kommt drauf an".

Die Idee von nem Distrikernel ist: bringe alles mit, was irgendwer irgendwann vielleicht mal brauchen könnte.
Die Idee von nem eigenen (minimalen) Kernel ist: hab nur das (wenn möglich fest einkompiliert) was Du auch wirklich brauchst.

Vorausgesetzt Du hast keinen Fehler in der Konfiguration gemacht, ist Deiner jetzt in allen Fällen sicherer, die darauf basieren, dass für den Angriff Modul xzy geladen werden kann. Da es bei Dir aber kein Modul xzy gibt (und der Code auch nicht fest einkompiliert wurde), sind alle Angriffe, die darauf basieren, dass xyz geladen werden kann, schonmal zum scheitern verurteilt.

Gehts hingegen um nen Bug der nur auftritt, wenn irgendwas von Compiler abc Version 47.11 fest einkompiliert worden ist, dann bist Du mit dem modularen Distri Kernel vermutlich besser dran.

Und dann gibts noch "Deine Config ist von Dir getestet" gegen "die Districonfig von vielen". Bugs finden viele oft gründlicher als man alleine. Und wie von bluestar schon genannt "Du musst Dich aktiv um Updates/Patches kümmern" gegenüber "die Distri macht das für Dich". Und wenn man noch länger nachdenkt, kann man bestimmt auch noch andere Punkte finden. Also ein klares "kommt drauf an".

[guennid]

(wenn möglich fest einkompiliert)

Warum?

[MSfree]

(wenn möglich fest einkompiliert)

Warum?

Ein Kernel, der keine Modulunterstützung hat und alle Treiber, die benötigt werden, fest einkompiliert hat, kann auch keinen Schadcode in Form von eingeschmuggelten Kernelmodulen nachladen.

Wenn man den Kernel sicherer machen will, reicht es also nicht, nur die Treiber fest einzukompilieren, man muß auch den Modulsupport ausschalten. Ansonsten bringt ein selbst gebauter Kernel keinen Sicherheitsgewinn. Man hat nur mehr Aufwand, den Kernel aktuell zu halten. Man kann mit einem selbst kompilierten Kernel etwas Plattenplatz sparen, allerdings braucht der Quellcoder und die nötige Entwicklungsumgebung ebenfalls Plattenplatz, was den eingesparten Platz wieder mehr als aufwiegt.

[guennid]

Danke für die Erläuterung!

Man hat nur mehr Aufwand, den Kernel aktuell zu halten.

Einleuchtend.

allerdings braucht der Quellcode und die nötige Entwicklungsumgebung ebenfalls Plattenplatz

den man nicht unbedingt auf derselben Maschine zur Verfügung stellen muss.

[Radfahrer]

Bei den heutigen Festplatten ist es natürlich auch ein riesen Vorteil, wenn man dreieinhalb Megabyte an Platz spart. Allein dafür lohnt sich die Arbeit doch schon.

[MSfree]

Bei den heutigen Festplatten ist es natürlich auch ein riesen Vorteil, wenn man dreieinhalb Megabyte an Platz spart. Allein dafür lohnt sich die Arbeit doch schon.

Alleine /lib/modules braucht 166MB unter Jessie

Ein monolitischer Kernel sollte normalerweise 4-5MB benötigen und auf die initrd kann man dann auch weitgehend verzichten, bzw sie läßt sich von 15MB auf ein paar hundert kB schrumpfen. Ich sehe da schon Sparpotential von rund 180MB.

Wer mit 4GB Plattenplatz auf einem EeePC zu kämpfen hat, ist dafür durchaus dankbar. Auf modernen Rechnern mit mindestens 128GB SSD ist das tatsächlich vergebliche Liebesmühe.

[cosmac]

Ein Original-Debian-Kernel würde doch vollautomatisch Updates bekommen wenn man unattended-upgrades installiert? Wäre das irgendwie auch mit einem eigenen möglich? Evt. funktioniert es noch für den Quelltext wenn man ein Debian-Paket verwendet. Aber welches? linux-source ist nur ein Meta-Paket, das bekommt ja kein Security Update und linux-source-$version wird evt. durch linux-source-$neue_version ersetzt. Selbst wenn das klappt, müsste man irgendwie ein "make" starten und dann?

OT: Ich muss evt. einen Rechner einrichten, bei dem die Firmen-Politik tägliche Updates verlangt, für den aber niemand zuständig ist. Sollte ein Update schief gehen, wird es irgendein Benutzer schon merken und hoffentlich rausfinden, wen er anrufen kann - so ist der Plan

[sergej2018]

Guten Morgen!

Entschuldigt meine späte Antwort.

Was ich mich noch frage: Warum eig einen Kernel patchen? In neueren Kernel-Versionen werden gefundene Fehler etc. doch vermutlich gefixt?
Könnte man nicht also einfach in regelmäßigen Abständen die neueste Kernel-Version für ein System kompilieren und wäre somit wieder auf dem Stand?
Das ist doch verhältnismäßig leicht machbar.

[bluestar]

Ich sehe da durchaus einige, potenzielle Probleme:

• Verträgt sich der neue Kernel mit deinem Userland - Kernel API kompatibel?

• Der neue Kernel enthält mit Sicherheit auch neuen Code, der wiederrum nicht 100%ig frei von Bugs ist und du somit eine neue Fehlerquelle eröffnest

[DEBIANUNDANDREAS]

Hallo die Kernelkompielierung ist zeitaufwendig ~45 Minuten!?

[sergej2018]

Zeitaufwendig?
Nein, auf nem halbweg aktuellen Prozessor (muss nix unheimlich schnelles sein) dauert das bei mir kaum 10 Minuten.

Was meinst du mit Userland und Kernel-API?

[bluestar]

Was meinst du mit Userland und Kernel-API?

Na z.B. kann es zu Kompatibilitätsproblemen zwischen Tools (iptables, mdadm, usw.) kommen, wenn der Kernel eine neuere Version der Tools voraussetzt.

[rendegast]

Evt. funktioniert es noch für den Quelltext wenn man ein Debian-Paket verwendet. Aber welches? Debianlinux-source ist nur ein Meta-Paket, das bekommt ja kein Security Update und linux-source-$version wird evt. durch linux-source-$neue_version ersetzt. Selbst wenn das klappt, müsste man irgendwie ein "make" starten und dann?

Zwei Möglichkeiten

Code: Alles auswählen

apt-get install linux-source-4.9

debiankernel.tar, rt.patch und config/ in /usr/src/.
Das tar muß entpackt und vorbereitet werden, zBsp. 'make allnoconfig'.
Unterschieben der eigenen config und Bauen/Paketerstellung mit Kerneltool:

Code: Alles auswählen

KCONFIG_CONFIG=deineconfig; export KCONFIG_CONFIG

make -j 3 deb-pkg binary

Code: Alles auswählen

apt-get source linux [-t stretch]

Die source-Dateien werden im aktuellen Verzeichnis heruntergeladen und vorbereitet.
Solange sich die source-Dateien nicht ändern, erfolgt kein weiterer Download.
Das Ergebnis entspricht obigem debiankernel.tar (OHNE den rt.patch) + debian/-Verzeichnis.
Dadurch können debian-Tools (fakeroot, dpkg-buildpackage usw.) zur Paketerstellung benutzt werden.
Wie hier eine eigene config untergeschoben wird?




Die erstellten debs landen in beiden Fällen letztlich in einem lokalen Repo und ermöglichen
mit passender Namens/Versionskreation (was tricky sein kann) automatische Upgrades.

[cosmac]

Dankeschön! Also es geht, aber wenn man zeitnahe Updates möchte, ist ein Eigenbau-Kernel nicht ganz trivial. Wenn man dabei ein .deb baut, muss man auch noch dafür sorgen, dass die Automatik auch für initrd und grub funktioniert