Kernel für SuSE System- ohne Module
Hello! Aus aktuellem Anlass stellt sich für mich derzeit folgende Frage: ein Kernel der die Möglichkeit zum Module nachladen deaktiviert hat sollte doch relativ sicher vor Rootkits sein, oder? (Damit meine ich nicht die Systemsicherheit allgemein, nur die Möglichkeit Rootkits zu laden bzw. aktivieren). Ist so ein Kernel einfach (= wie immer) zu bauen oder gibt es dabei "Solperfallen"? mfg. Michael Hirst -- Michael Hirst - mike@agildev.com agildev - Softwareentwicklung - Projektentwicklung - Projektmanagement http://www.agildev.com Rosentalgasse 10/5 1140 Wien Tel.: +43/1/9909182
Am Dienstag, 17. Mai 2005 20:09 schrieb M. Hirst:
Aus aktuellem Anlass stellt sich für mich derzeit folgende Frage:
ein Kernel der die Möglichkeit zum Module nachladen deaktiviert hat sollte doch relativ sicher vor Rootkits sein, oder? (Damit meine ich nicht die Systemsicherheit allgemein, nur die Möglichkeit Rootkits zu laden bzw. aktivieren).
Relativ, ja. Dazu noch ne separate /boot Partition die nur ro gemounted wird, das hält zwar keine Profi-Hacker ab, aber Script-Kiddis die nur vorgefertigte Shellscripte starten sind schon mal aussen vor.
Ist so ein Kernel einfach (= wie immer) zu bauen oder gibt es dabei "Solperfallen"?
Du musst alles drin haben, was Du benötigst und auf Treiber verzichten, die nur als Modul funktionieren. All das non GPL-Zeugs wie AVM-Treiber sind also aussen vor. Und natürlich darfst Du bei jeder Sicherheitlücke wieder nen eigenen Kernel backen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Manfred Tremmel wrote:
[...] Du musst alles drin haben, was Du benötigst und auf Treiber verzichten, die nur als Modul funktionieren. All das non GPL-Zeugs wie AVM-Treiber sind also aussen vor. Und natürlich darfst Du bei jeder Sicherheitlücke wieder nen eigenen Kernel backen.
Manchmal will es auch nicht funktionieren, wenn man zwei spezifische Features zusammen direkt in den Kernel einbindet und nicht als Modul realisiert; es scheint da dann zu Konflikten zu kommen. Und bei z.B. mehreren SCSI-Adapterkarten o.ae. kann das Einbinden ueber ein Modul zwecks Reihenfolge der Erkennung auch nuetzlich sein. Theoretisch sollte sich so ein Kernel also bauen lassen, haengt ein bissl von der eingesetzten Hardware ab, im Einzelfalle kann es aber zu Problemen kommen; insbesondere wenn man Treiber von NVIDIA oder ATI einsetzen will, ist das vorprogrammiert... Was evtl. einfacher ist, ist das automatische Nachladen von Modulen zu verhindern - so kann man den Kernel modular ganz normal booten, bis das System hochgefahren ist, danach wird das automatische Laden von weiteren Modulen verhindert; wenn allerdings jemand Root-Rechte auf besagter Maschine hat, kann er das wieder aendern, oder natuerlich direkt /sbin/modprobe aufrufen, aber in dem Falle ist dann eh alles schon zu spaet... Der Kernel nutzt das in /proc/sys/kernel/modprobe angegebene Programm zum automatischen Nachladen von Modulen. Wenn Du also nach dem Booten eine entsprechende Aenderung an dieser Datei im Pseudo-Filesystem proc machst, sollte der Kernel nichts mehr Nachladen koennen an Kernel-Modulen... Cheers, Th.
On Tuesday 17 May 2005 23:09, Thomas Hertweck wrote: [...]
Was evtl. einfacher ist, ist das automatische Nachladen von Modulen zu verhindern - so kann man den Kernel modular ganz normal booten, bis das System hochgefahren ist, danach wird das automatische Laden von weiteren Modulen verhindert; wenn allerdings jemand Root-Rechte auf besagter Maschine hat, kann er das wieder aendern, oder natuerlich direkt /sbin/modprobe aufrufen, aber in dem Falle ist dann eh alles schon zu spaet...
Wenn jemand root-Rechte hat, kannst du dir jeglich Maßnahmen sparen, dann ist allenfalls noch eine Crypto-Partition sicher. Mal abgesehen davon sind ja Module eh nicht das alleinige Einfallstor. Bufferoverflows oder Sicherheitslecks im ELF-Binary-Loader kannst du damit auch nicht verhindern. Das ganze bringt wohl eher mehr Probleme (z.B. beim suspend) als die erlangte trügerische Sicherheit. Gruß, Danny
Hallo! Danke für euere Tipps und Beiträge. Das ganze sollte für einen Server sein, daher sind Probleme wie zB Suspend oder wechselnde Hardware nebensächlich. Es ist (bzw. wäre) natürlich auch nicht die einzige Aktion gewesen um das Ding abzusichern. Es war nur eine Überlegung ob ich so, auch doch recht simple Weise, mehr Sicherheit bekomme. mfg. Michael Hirst -- Michael Hirst - mike@agildev.com agildev - Softwareentwicklung - Projektentwicklung - Projektmanagement http://www.agildev.com Rosentalgasse 10/5 1140 Wien Tel.: +43/1/9909182
participants (4)
-
Danny Kukawka -
M. Hirst -
Manfred Tremmel -
Thomas Hertweck