Moins!
Jetzt hat mich das erwischt, was vielen Linux-Nutzer wahrscheinlich längst in Fleisch und Blut übergegangen ist. Ich brauche eine Funktionalität, die mein aktueller Kernel nicht von Hause aus unterstützt und muss einen eigenen Kernel kompilieren. Im konkreten Fall geht es IPv6-Unterstützung (anycast 6to4).
Ich setze bisher ausschliesslich die binary-distri von woody ein und will den Pfad auch weitestgehend beibehalten, weil mir im grossen und ganzen Stabilität wichtiger ist als die neuesten Features.
Meine Fragen: - Wie ist die sinnvollste Strategie, damit ich nicht anfangen muss, die distri allzusehr zu vermurksen? Alles, was ich dazu gefunden habe setzt entweder Wissen voraus, dass ich (noch) nicht habe, scheint mehr oder weniger outdated zu sein oder zwingt mich Wege zu gehen, die ich nicht einschlagen will.
- Es gibt bei stable nach wie vor den hässlichen ungepachten ptrace-Bug. Sinnvollerweise würde ich gerne einen Kernel kompilieren, bei dem dieses Problem nicht auftaucht und ich nicht den /proc-Workaround benutzen muss. Was muss ich tun?
- Hat jemand bisher Erfahrung im Zusammenhabg IPv6 und Security gesammelt? Wenn ja, gibt es dabei besondere Dinge zu beachten, die über das Wissen über IPv4 weit hinausgehen?
Schönen Tag noch, Christian Horchert
On Dienstag, 8. April 2003 22:01 I heard you say:
Meine Fragen:
- Wie ist die sinnvollste Strategie, damit ich nicht anfangen muss, die distri allzusehr zu vermurksen? Alles, was ich dazu gefunden habe setzt entweder Wissen voraus, dass ich (noch) nicht habe, scheint mehr oder weniger outdated zu sein oder zwingt mich Wege zu gehen, die ich nicht einschlagen will.
Wieso vermurksen? Du kompilierst deinen Kernel, deine Module, installierst beides und passt deine lilo.conf bzw. menu.lst an. Viel kannst du da nicht falsch machen. Dem Kernel liegt doch eine Readme bei in der alles idiotensicher beschrieben ist.
- Es gibt bei stable nach wie vor den hässlichen ungepachten ptrace-Bug. Sinnvollerweise würde ich gerne einen Kernel kompilieren, bei dem dieses Problem nicht auftaucht und ich nicht den /proc-Workaround benutzen muss. Was muss ich tun?
http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.21-pre7.bz2
* Christian Horchert wrote:
Moins!
Jetzt hat mich das erwischt, was vielen Linux-Nutzer wahrscheinlich längst in Fleisch und Blut übergegangen ist. Ich brauche eine Funktionalität, die mein aktueller Kernel nicht von Hause aus unterstützt und muss einen eigenen Kernel kompilieren. Im konkreten Fall geht es IPv6-Unterstützung (anycast 6to4).
Benutzer in die Gruppe src einfügen, ausloggen, einloggen, freuen. Kernelsourcen nach /usr/src auspacken, z.B. make xconfig ausführen, Konfiguration von /boot/config-irgendwas laden.
Nach Eigenbedarf ändern, make-kpkg kernel-image -revision= meinkernel.1 ausführen. Als root dpkg -i meinkernel*.deb installieren. Lilo/Grub anpassen, neustarten, freuen.
Meine Fragen:
- Wie ist die sinnvollste Strategie, damit ich nicht anfangen muss, die distri allzusehr zu vermurksen? Alles, was ich dazu gefunden habe setzt entweder Wissen voraus, dass ich (noch) nicht habe, scheint mehr oder weniger outdated zu sein oder zwingt mich Wege zu gehen, die ich nicht einschlagen will.
Das Debianbuch von Ganten, ist für Potato, hat mir sehr gut geholfen. Und auf www.openoffice.de findet man auch sehr gute Hilfe.
- Es gibt bei stable nach wie vor den hässlichen ungepachten ptrace-Bug. Sinnvollerweise würde ich gerne einen Kernel kompilieren, bei dem dieses Problem nicht auftaucht und ich nicht den /proc-Workaround benutzen muss. Was muss ich tun?
Meine Meinung: für den Hausgebrauch nicht relevant. Wobei meine Meinung auch nicht relevant ist. ;-)
Grüße Jan
On Tue, Apr 08, 2003 at 10:01:38PM +0200, Christian Horchert wrote:
Ich setze bisher ausschliesslich die binary-distri von woody ein und will den Pfad auch weitestgehend beibehalten, weil mir im grossen und ganzen Stabilität wichtiger ist als die neuesten Features.
Normalerweise (auf Maschinen, auf denen öfter mal ein Kernel gebraucht wird) mach' ich das mit
make menuconfig bzlilo modules{,_install}
Wenn Du den schönen Debian Way of Life gehen willst, dann willst Du kernel-package installieren und
make-kpkg --revision meiner.1 binary
(oder zur Info: make-kpkg targets) machen und hast anschließen u.a. ein kernel-image-*deb, welches Du installieren kannst.
- Es gibt bei stable nach wie vor den hässlichen ungepachten ptrace-Bug. Sinnvollerweise würde ich gerne einen Kernel kompilieren, bei dem dieses Problem nicht auftaucht und ich nicht den /proc-Workaround benutzen muss. Was muss ich tun?
2.4.20 von kernel.org holen, auspacken und los gehts. Ggü dem Kernel von Debian ist wohl nur ein Patch für die initrd dort nicht drin... nimm also einfach keine initrd.
Heiko
Hallo!
Am 2003-04-09 2:02 +0200 schrieb Heiko Schlittermann:
- Es gibt bei stable nach wie vor den hässlichen ungepachten ptrace-Bug. Sinnvollerweise würde ich gerne einen Kernel kompilieren, bei dem dieses Problem nicht auftaucht und ich nicht den /proc-Workaround benutzen muss. Was muss ich tun?
2.4.20 von kernel.org holen, auspacken und los gehts. Ggü dem Kernel von Debian ist wohl nur ein Patch für die initrd dort nicht drin... nimm also einfach keine initrd.
Da wäre ich verdammt vorsichtig. Bei mir hat der Bug auf einem vanilla 2.4.20 funktioniert (ohne grsecurity)!
Du solltest lieber die 2.4.21-pre7 riskieren, dort ist der Bug behoben, und dann, wenn 2.4.21 rauskommt, nochmal kompilieren.
Einen schönen Tag noch!
Martin
On 09.04.03 Martin Pitt (martin@piware.de) wrote:
Am 2003-04-09 2:02 +0200 schrieb Heiko Schlittermann:
2.4.20 von kernel.org holen, auspacken und los gehts. Ggü dem Kernel von Debian ist wohl nur ein Patch für die initrd dort nicht drin... nimm also einfach keine initrd.
Da wäre ich verdammt vorsichtig. Bei mir hat der Bug auf einem vanilla 2.4.20 funktioniert (ohne grsecurity)!
Ja klar, sonst wäre es ja kein bug. Hey, das ist ein *lokaler* Exploit. Der OP hörte sich nicht so an, als ob er einen Riesenserver mit 1000 Nutzern betreibt, der akut gefährdet ist. Patches für ptrace gibts auf der LKML.
Du solltest lieber die 2.4.21-pre7 riskieren, dort ist der Bug behoben, und dann, wenn 2.4.21 rauskommt, nochmal kompilieren.
gcc -D__KERNEL__ -I/usr/src/linux-2.4.20/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -DMODULE -nostdinc -iwithprefix include -DKBUILD_BASENAME=ac97_codec -DEXPORT_SYMTAB -c ac97_codec.c ac97_codec.c:131: `AC97_NO_PCM_VOLUME' undeclared here (not in a function) ac97_codec.c:131: initializer element is not constant ac97_codec.c:131: (near initialization for `ac97_codec_ids[12].flags') <snip> make[2]: *** [ac97_codec.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.20/drivers/sound' make[1]: *** [_modsubdir_sound] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20/drivers' make: *** [_mod_drivers] Error 2 drachi:[/usr/src/linux] #
auch dafür gibts wohl patches.
H.
lug-dd@mailman.schlittermann.de
-
Christian Horchert -
Heiko Schlittermann -
Hilmar Preusse -
Jan Rakelmann -
Martin Pitt -
Martin Weissbach