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 >