## c't-Projekte - Mailinglisten

[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

### AW: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen

Absender: Jens Friedrich
Datum: Di, 20.12.2005 23:29:21
In-reply-to: <Pine.LNX.4.58.0512202147000.14583@xxxxxxxxxxxxxxxxxxxx>

    Mir geht's mehr um die -fstack-protector option des gcc, die ist im LFS ja
    extra eingebaut - und wir schalten die aus?
    Ich find die Idee dieses Patches / der Option gut...

    Den propolice-patch...ok - den könne ma rauslasse... ;-)
    Sehe ich auch so.

    Zum Thema Stacks schützen + FW hat dann schon versagt: JEIN  ;-)
    Wenn die FW nen Stack-Overflow evtl. abfängt (statt zu "halt"en oder
    "core"en oder so)
    und stattdessen weiterläuft trägt das nicht zur UML-IPCop Stabilität bei?

    Und was ist mit den ganzen AddOns, die teilweise installiert werden?
    OK - die laufen evtl. im Userspace... Aber nicht alle, oder (QoS?!)
    Die würden unter obiger Annahme evtl. auch nicht gleich zu einem Abbruch
    führen... (??)

    Wenn mein umlipcop1.4.10-vc1.patch läuft, wird ich mal den TT-MODE
    rausnehmen, und
    schauen was passiert... Oder hat's schon jemand getestet?

    Viele Grüsse
    Jens

    > -----Ursprüngliche Nachricht-----
    > Von: ctsrvdev-bounces@xxxxxxxxxxxxxxxxx
    > [mailto:ctsrvdev-bounces@xxxxxxxxxxxxxxxxx] Im Auftrag von
    > Peter Siering
    > Gesendet: Dienstag, 20. Dezember 2005 22:25
    > An: Entwicklung rund um den c't Server
    > Betreff: Re: AW: AW: [ctsrvdev] Ipcop innerhalb der
    > ipcop-umgebung bauen
    >
    > Hallo,
    >
    > On Tue, 20 Dec 2005, Jens Friedrich wrote:
    >
    > > Also, Peters Methode innerhalb der ipcop-LFS habe ich jetzt mit
    > > Ipcop-1.4.10 am laufen...(besser gesagt kompiliert, ausprobiert hab
    > > ich das Ding nämlich noch nicht...)
    > >
    > > Allerdings mit den beschriebenen Hack's (Propolice raus, und
    > > -fno-stack-protector-all Option).
    > >
    > > Das mit dem Propolice-Patch wird also nur ausserhalb der
    > LFS-Umgebung
    > > gehen, keine Ahnung wo man da drehen müsste :-(
    > >
    >
    > Mir ist ein weiterer Zusammenhang aufgefallen, den ich hier
    > noch mal explizit erwähnen möchte: Der Fehler beim Übersetzen
    > tritt (nur?) dann auf, wenn der IPCop/UML-Kernel statisch
    > gebunden wird -- das ist beim Aktivieren des tt-Modes der Fall.
    >
    > Den tt-Mode habe ich erst mit 1.4.6 (c't-Server 1.1)
    > aktiviert, um ein statisches Binary des IPCop-UML-Kernel zu
    > bekommen. Die eigentliche dafür vorgesehen UML-Option hatte
    > damals macken, sodass die UML-Entwickler zu tt-Mode rieten.
    >
    > Die Version 1.4.2 kam noch ohne tt-Mode aus und hatte
    > entsprechend den Stack-Protection-Kram drin.
    >
    > > Peter meint ja, das damit der Kernel näher am IPCop-kernel ist.
    >
    > Das ist ein Streit um des Kaisers Bart, wenn ich 180 KByte
    > komprimierten Patch in den Kernel einspiele ;-)
    >
    > > Ich meine das nicht - ich denke das mit der Stack-Protection ein
    > > Firewall-Kernel besser ist, auch wen ich den ausserhalb der LFS
    > > Kompiliere.
    > >
    >
    > Habt Ihr den Hinweis auf den lkml-Thread zu propolice mal verfolgt?
    > (http://www.ussg.iu.edu/hypermail/linux/kernel/0501.1/1789.htm
    > l wie in
    > http://www.heise.de/ct/ftp/projekte/srv/srcdoc/ipcop.shtml erwähnt)
    >
    > Ich denke, das Firewall-Kernel hier als Argument kaum zählen
    > kann: Wenn ich erst die Stacks auf meiner Firewall schützen
    > muss, hat sie doch schon versagt oder ;-?
    >
    > > Wer bietet mehr?
    >
    > Wichtig ist Reproduzierbarkeit: Die ist bei der Integration
    > in die IPCop-Buildumgebung gegeben.  Und:  Die Aussicht, dass
    > die IPCop-Entwickler die Änderungen übernehmen, ist größer.
    >
    > Wenn ich den IPCop-UML-Kernel aber im Wirtssystem übersetze,
    > dann ist das für meinen Eindruck kaum reproduzierbar, selbst
    > wenn man Sarge als Basis festschreiben würde, von anderen
    > Distributionen muss man wohl nicht reden ...
    >
    > Könnt Ihr sicher sein, dass der Kernel für den Schutz der
    > Stacks nicht mit einem geeignet gepatchten Compiler zu
    > übersetzen ist? In der LFS-Umgebung läuft - zumindest auf den
    > ersten Blick - ein gepatchter gcc - womöglich bleibt der
    > ganze Schutz beim Übersetzen mit dem Wirts-gcc auf der Strecke?
    >
    > Peter
    >
    > _______________________________________________
    > ctsrvdev Mailingliste
    > ctsrvdev@xxxxxxxxxxxxxxxxx
    > http://www.heise.de/bin/newsletter/listinfo/ctsrvdev
    >

- Referenzen:
  - Re: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen
    - From: Peter Siering

- Voriger (Datum): Re: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Peter Siering
- Nächster (Datum): AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Jens Friedrich
- Voriger (Thread): Re: AW: AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Peter Siering
- Nächster (Thread): AW: [ctsrvdev] Ipcop innerhalb der ipcop-umgebung bauen, Jens Friedrich
- Indizes:
  - Datum
  - Thread