Kernel und Sicherheitslücken

[killerhorse]

Hallo,

Habe auf meinem Server Debian Sarge + selbstkompilierten 2.6er Kernel. Hab ihn unter anderem deswegen selbst kompiliert, weil ich aus Sicherheitsgründen keine Module nutzen möchte. Ausserdem bin ich mit dem Standardkernel von Debian garnicht klargekommen, bereits ein Portscan auf den Server hat die Last extrem ansteigen lassen...

Da immer wieder Sicherheitslücken gefunden werden, die im akuellen Linux Kernel ausgebessert wurden, hab ich gedacht, kann ich nichts falsch machen, wenn ich den Kernel einfach aktuell halte.
Das Problem ist jetzt aber, dass ich einen Kernelpatch einspielen möchte, den es für den aktuelenKernel nicht gibt, nur für den 2.6.17.13. Ausserdem ist es auch nicht gerade so toll, wenn ich dauernd den Server rebooten muss...

Wie bekomm ich eigentlich möglichst schnell einen Überblick welche kritischen Sicherheitslücken seit z.B. 2.6.17.13 gefixt wurden? Weil es ist ja nicht gesagt, dass mich diese überhaupt betreffen. Eventuell wurden ja auch Sicherheitslücken bei neuen Features gefunden die dann in einer weiteren Version behoben wurden... Dabei bin ich ja eigentlich mit einem 2.6.17 Kernel zufrieden und brauch keine neuen Features.
Wenn ich mir die ganzen Changelogs durchlese gibts wieder drei neue Versionen bis ich fertig....


Wie geht ihr mit der Sache um?

MfG

Christian

[captaincrunch]

weil ich aus Sicherheitsgründen keine Module nutzen möchte.

Dir ist aber schon bewusst, dass es seit mehreren Jahren Mittel und Wege gibt, auch nicht-modulare Kernel zu unterwandern (sofern sie nicht entsprechend auch dagegen gesichert wurden)?

Sofern es einen spezielle Kernelpatch wirklich nur für eine spezielle Kernelversion gibt: je nach Patch lässt sich die Sache meist innerhalb von ein paar Minuten umschreiben.

[killerhorse]

Dir ist aber schon bewusst, dass es seit mehreren Jahren Mittel und Wege gibt, auch nicht-modulare Kernel zu unterwandern (sofern sie nicht entsprechend auch dagegen gesichert wurden)?

Wenn man davon ausgeht, kann man ja gleich auf Sicherheit Pfeiffen, den irgendine Möglichkeit den Server zu knacken wird es immer geben. Es geht aber darum soviele Möglichkeiten wie möglich auszuschalten und es einem möglichen Angreiffer so schwer wie möglich zu machen und das bei möglichst geringer Einschränkung der Funktionalität.

Allerdings ist das nicht wirklich meine Frage. Die Frage ist eben z.B. WIe mach ich das mit dem Kernel, wenn ich den Kernel Patch des Linux-VServer Projekts einspielen will?
Den gibts eben nur für 2.6.17.13 oder der von OpenVZ sogar nur für 2.6.9.

Generell müsste ich wenn ich immer den 2.6er Kernel haben möchte, der laut kernel.org "stable" ist, alle paar Tage einen neuen Kernel bauen und die Patches kann ich dann auch nicht verwenden.

MfG

Christian

[captaincrunch]

Die Frage ist eben z.B. WIe mach ich das mit dem Kernel, wenn ich den Kernel Patch des Linux-VServer Projekts einspielen will?

Wenn du's "sicher" haben willst, habe ich dir die Frage schon vorab beantwortet: schreib den Patch entsprechend um.

Den gibts eben nur für 2.6.17.13 oder der von OpenVZ sogar nur für 2.6.9.

Die OpenVZler nehmen die die Arbeit ab, und packen Sicherheitsfixes direkt mit in ihr Patchset.

Generell müsste ich wenn ich immer den 2.6er Kernel haben möchte, der laut kernel.org "stable" ist, alle paar Tage einen neuen Kernel bauen und die Patches kann ich dann auch nicht verwenden.

Daher weiß man halt auf einem produktiven Server entweder sehr genau, was man tut, oder nutzt Kernel "von der Stange", also die, die deine Distri für einen mitliefert.

[killerhorse]

Hallo,

Das Problem ist, dass der mitgelieferte Debian Kernel

1. SEHR ALT ist und ich damit nichtmal den SMART Status der Festplatten (SATA) auslesen kann

2. Ist es wie gesagt ein modularer kernel. Es wird unter anderem in einem Buch das hier in den Buchtips steht AUSDRÜCKLICH von einem modularem Kernel abgeraten.

Ansonsten würde mich wie gesagt interessieren wie ihr die Sache handhabt. Verwenden die meisten am Ende doch einen "normalen" modularen Kernel (z.B. den der mitgeliefert wurde)?

Was die Sache mit dem "Patch umschreiben" betrifft... Sorry, ich bin kein Programmierer, habe gerade mal ein paar C Grundkenntnisse, die sicherlich nicht ausreichen um den gesammten Quelltext des Kernels zu verstehen und im detail zu verstehen was bei der akuellen Version genau geändert wurde. Somit weiss ich auch nicht was an dem Patch nicht mir dem akuellen Kernel kompatibel ist und was geändert werden muss.

Wenn es so leicht wäre den Patch an den aktuellen Kernel anzupassen und das so, dass das ganze trotzdem wirklich stabil läuft, dann frage ich mich, warum das nicht die Entwickler des jeweiligen Projekts machen.

MfG

Christian

[daemotron]

Wenn Du Wert auf aktuelle Kernel-Releases legst, kommst Du ums (häufige) selber bauen eh nicht drumherum. Wenn Du Dir dabei das Patchen (und ggf. portieren von Patches) nicht antun willst, kannst Du mit einem kleinen Trick die Kernel von Gentoo verwenden - die stellen Kernel-Sources mit allen möglichen und unmöglichen Patches bereit (schau mal hier: http://packages.gentoo.org/search/?sstring=sources).

Da Du Debian hast und vermutlich nicht auf Gentoo wechseln willst (wenn doch tu Dir keinen Zwang an ), musst Du ein bisschen tricksen, um an die Quellen zu kommen. Leg Dir auf Deiner Kiste ein Verzeichnis an, in dem Du ein Gentoo im chroot installierst (Anleitung z. B. hier). In der chroot-Umgebung übernimmt emerge den Download und das patchen der Kernel-Quellen (hier im Beispiel openvz-sources):

Code: Select all

emerge openvz-sources

Danach musst Du nur noch das entsprechende Verzeichnis mit den Quellen in Dein Hauptsystem verschieben:

Code: Select all

cd /chroot/usr/src
cp -r linux-openvz-xx.xx.xx /usr/src/
cd /usr/src
ln -s linux-openvz-xx.xx.xx linux

Danach kannst Du den Kernel ganz normal bauen; der Aufwand bei einem Update des Kernels besteht hauptsächlich im kopieren der Sourcen und der Überprüfung der Konfiguration.