OK, bin grad am Konfigurieren des Kernel 2.6.4, und da is auch der AMD PCnet32-Treiber dabei. Und wenn ich heute noch fertig werd, kann ich während dem Compilieren ja noch a bissl was für SysProg machen… 
saubere sache 
Huh, da lässt man den Rechner mal kurz allein, dann is der Kernel auch schon fertig… Aber leider verträgt sich VMware noch nicht damit. Eigentlich läuft es ja ganz gut, aber kurz nach den “paride”-Meldungen beim booten (brauch ich das überhaupt?) kommt ne Fehlermeldung von VMware, dass da irgendwas seltsames in der “vcpu-0” “NOT_IMPLEMENTED” wäre. Es folgen 23k debug log.
Hmm, ich hab den Kernel gestern nochmal neu gemacht, hab ein paar Sachen rausgeworfen, u.a. dieses paride-Zeug, kein Plan wofür das gut sein soll. Nur leider ist das Image jetzt scheinbar zu groß, warum auch immer. Die Dateigröße ist allerdings kleiner als vorher. Ich bekomm jetzt also direkt nach LILO eine Meldung, dass was nicht passt. Was kann ich da tun? initrd? Module (die ich aus Sicherheits- und don’t-need-Gründen rauslassen wollte)? Das Image ist etwas weniger als 2MB groß.
Hey, da kommt mir grad was. Kann man den Kernel nicht mit unterschiedlichen Algos packen? Hast du sicher wieder make bzImage benutzt und nicht z.B. zImage? Irgendwas gab’s da doch in der Art, oder?? (Frage an die Linux-Vollchecker)
bzImage. Was anderes hab ich nir ausprobiert, bin einfach nur deiner Befehlsfolge gefolgt…
Hm, ich glaub ich hab irgendwann mal versehentlich nur make zImage gemacht dann kam die Meldung, der Kernel wäre zu groß und ich sollte doch mal bzImage versuchen, weil das den Kernel kleiner mach (was ja kein Wunder ist, da bzip2 komprimiert als das olle gzip)
irgendwas hast du bestimmt falsch gemacht, initrd braucht man eigentlich nur, wenn man auf module angewiesen ist, z.B. von diversen software-raid-controllern, die geladen werden müssen, bevor der kernel die rootpartition lesen kann.
würde mich wundern wenn dein kernel also so schon zu groß wird… und im übrigen, was haben module mit sicherheit zu tun??
Was Module mit Sicherheit zu tun haben? Ich hab da mal was von diesem tollen ptrace() Bug gehört. Bin mir nicht mehr sicher, aber der war doch ne Lücke im Kernel-Modul-Zeugs, oder? Naja, und wenn ich die net brauch, kann ich sie auch rauslassen. Dieser Bug ist zwar mittlerweile behoben, aber mir gefällt irgendwie die Idee nicht so recht, dass man von außen irgendwas in den Kernel reinstöpseln kann…
Aber das Problem hat sich mittlerweile erledigt. Ich hab irgendwo im Netz einen neuen LILO gefunden, der von Debian stable is scheints zu alt. Mit dem neuen ging’s dann problemlos. Kernel 2.6.4 läuft jetzt wunderbar!
Ziemlich idiotische Sichtweise, aber gut.
Module sind leichter zu manipulieren als der Kern selber. Wenn ein Benutzer Schreibrechte auf ein Modul bekommt das automatisch geladen wird, ein eigenes Modul explizit laden kann, eigenen Quellcode unterjubeln kann etc, hat er ein Modul im Kern und damit Vollzugriff.
In einem sauber konfigurierten System sollte sowas zwar nicht vorkommen, aber Minimierung der Angriffsflaeche ist eben Grundprinzip der Sicherheit, deswegen wenn unnoetig Modulladen abschalten. Nachdem man fast immer Sachen hat die Module brauchen ist des nur fuer Router und andere sicherheitsrelevante Rechner interessant.
Wenn er die Module in /lib/modules/ schreiben kann, hat er bereits Vollzugriff.