[linux-l] Slightly off topic: Jagd auf Spam

[Jan Krueger]

Hi Peter :)

On Saturday 25 October 2003 16:43, Peter Ross wrote:
(sinngemäß und stark verändert und verkürzt wiedergegeben)
Im einzelnen:
> - StackProtector, ProPolice, Randomization
Es wurde von Fachleuten gezeigt, daß diese Schutzmechanismen sich aushebeln 
lassen. (Ich verzichte mal auf Referenzen, da ich mich grad für etwas anderes 
interessiere habe ich sie Moment nicht zur Hand.)

> - W^X
Ist im Falle von OpenBSD "kooperativ" also vom Administrator und wie er die 
Anwendung zusammenbaut abhängig, läßt sich also nicht systemweit "enforcen" 
wie z.b. bei Linux. W^X kann nicht schützen was z.b. innerhalb einer VM 
abläuft (Java, Erlang) und Auswirkungen auf das System haben kann. W^X (und 
damit auch BeLUG Patent 00022003) ist kontraproduktiv bei Hochsprachen, 
welche es erlauben, z.b. um eine hohe Verfügbarkeit zu erreichen, Code zur 
laufzeit zu ersetzen ([Native-]Lisp, [Native-]Erlang als Beispiel)

[BTW eine faktische, praktische Größe aus dem realen Erlang Leben: Ericsson 
AXD 301, an ATM switch with 99.9999999 percent reliability (9 nines, or 31 
ms. downtime a year), which has captured 11% of the world market. The AXD 301 
system includes 1.7 million lines of Erlang.]

Des weiteren ist W^X kontraproduktiv bei Sprachen welche es erlauben komplette 
Funktionen als Parameter zu übergeben (nicht nur als Referenz) oder gar 
Funktionen die Funktionen generieren, welche wiederum Funktionen generieren 
usw. (zb. lernende, sich selbst evolutionierende Systeme).
Ich erinnere mich von zumindest theoretischen Ansätzen gelesen zu haben, wie 
man W^X aushebeln kann.

> - grsecurity, chflags, capabilities, acl, RSBAC, IDS, *-Scanner, *-Filter,
> Firewalls ...
... fügen einem System ein hohes Maß an Komplexität hinzu. Firewall Regeln, 
Policies jeglicher Art usw. sind nicht trivial und man kann auf den 
entsprechenden Mailinglisten/Foren die Administratoren fluchen lesen. Und 
keiner kann sich sicher sein, daß er wirklich alles im Griff hat. Hat die 
neue Kernelversion einen syscall verändert, hinzugefügt, der von der Policy 
noch nicht/unvollständig/falsch erfasst wird? Hier "hilft" auch ein Blick in 
die Windows-Welt. Viele Windows-Admins sagen: "policies, cool feature" und 
wenn sie die Policy erstellen müssen: "ahh, its so complicated, sh* policy 
editor, usw." und wenn sie nach einem Jahr die Policy ändern müssen: "sh* f* 
f* f* Policy! Its better, easyer, faster to create a new one." und auch dann 
dauert es wieder Tage bis sie fertig ist. Das ist mit acls, RSBAC und 
grsecurity usw. nicht viel anders.
über den Sinn und Unsinn von chflags kann man sich streiten. Es ist paktisch 
um sich als root vor Dummheiten zu schützen.

> - jails, chroot, UML, VM´s, Maschinen-Partitionierung,
> - privilege separation ...
Apache, php und ähnliche komplexe Konstellationen mit chroot absichern zu 
wollen bekommt schnell masochistischen Charakter. Dabei war chroot noch nie 
wirklich sicher (wirkt ja nur auf den Namespace), mit jails ist es etwas 
besser. UML, VM's, Partitionierung kann enorm helfen die Integrität einzelner 
Dienste zu sichern. Gleichzeitig klingt das auch irgendwie nach "Microkernel"  
mit entprechend aufgesetzten Servern (Server hier im Microkernel-Sinne 
gemeint) oder "Exo-Kernel"

> - summasummarum ...
... sind das alles Technologien welche den ungeheuerlichen Aufwand 
verdeutlichen, welcher betrieben wird um die Symptome zu fixen an Stelle die 
Ursachen zu beseitigen.

> Die Kombination solcher Mittel fuehrt schon sehr weit.
Du hast recht. Mir jedoch geht das mit den Mitteln zu weit und ist, meiner 
Ansicht nach, eher geeignet den Admin in die Klappsmühle zu befördern als 
irgendwas abzusichern.

> Um mit so einem
> Rechner etwas anzustellen, musst Du ein halbes Dutzend Sicherheitsluecken
> haben, um soweit zu kommen, dass Du tun und lassen kannst, was Du willst.
Eben nicht, es reicht immer noch eine einzige Sicherheitslücke aus, wie vorher 
auch. Und meiner Ansicht nach wird die Wahrscheinlichkeit für eine 
Sicherheitslücke durch die enorme zusätzlich eingebrachte Komplexität nicht 
verringert, eher die Wahrscheinlichkeit für einen administrativen Fehler und 
darauffolgende Sicherheitslücke erhöht. Menschen sind immer noch die größten 
"Schwachstellen" bei dem ganzen und das liegt nicht an den Menschen! sondern 
an den menschenunfreundlich gestalteten, hyperkomplexen Technologien.
Schicht 8 Fehler und so, hatten wir ja auch neulich in der Liste. Anders 
ausgedrückt: Welche der genannten Technologien machen es dem Menschen gerecht 
sein System abzusichern? Warum muß er sein System überhaupt absichern? Warum 
ist es nicht einfach sicher?

> Die Frage hier ist, wieweit kannst Du das noch so gestalten, dass nicht
> der Nutzer zwei Jahre braucht, bis der Rechner ans Netz geht..
Genau. Nicht der Nutzer ist falsch, sondern die Technologie, wenn das System, 
wenn es sicher sein soll, 2 Jahre zum booten braucht.

> Die Spammer im genannten Text waeren da schon dran gescheitert.
Er hätte etwas anderes gefunden, zum beispiel auf Schicht 8. Es gibt einfach 
zu viele die an einer "Special Offer" interessiert sind. Das ist meiner 
Ansicht nach irgendwo auch ganz natürlich und verständlich. Damit ergibt sich 
Spam als ein Nicht-Technisches Problem welches sich auch in meinem 
Blech-Briefkasten findet. Somit kann bei der Verhinderung von Spam die 
Technik allenfalls unterstützenden Charakter haben.

Folgend möchte ich meine bisherigen Erkenntnisse zusammenfassend und ausholend 
darlegen. Wir, im Sinne von OpenSourceCommunity oder zumindest einige/viele 
davon, nutzen oder streben nach:

-posix, einen inkonsistenten, komplizierten, benutzerunfreundlichen (mit zb. 
Programmierern als Nutzer), unsicheren Standard
-single unix spezifikation, s.o. (mit Nutzern als Nutzer)
-c, c++, unsichere Programmiersprachen
-std c-lib, c++-lib mit unsicheren funktionen und tückischen Tücken
-monolytische kernel, die Kompromittierung des (ausreichend komplizierten) 
Netzwerk-Stacks/Treibers reicht aus um alles mit Kernelrechten machen zu 
können und/oder das System außer Gefecht zu setzten, von den noch viel 
zahlreicheren lokalen Möglichkeiten ganz zu schweigen (welche sich hier und 
da [php] auch übers Netz lassen)
-diverse andere, manchmal selbst kreierte, Standards ("Kompatibilität") 
welcher Benutzerfreundlichkeit und Sicherheit im Wege stehen
-schmeißen das alles in einen großen Topf und ahmen nach, was Microsoft/Apple 
vor machen ohne dabei aus deren Fehlern zu lernen (ich sag nur: KDE + 
Konqueror, Gnome + CORBA)
-ignorieren organisatorische Probleme (Softwareverteilung, 
Entwicklungsprozess)
-QA (Qualitätsicherung) existiert häufig nicht wirklich. Die QA von 
Rotkäppchen ähnelt mir viel zu stark der von MS, Susie wird nicht viel anders 
sein. Sämtliche offenen Projekte haben keine wirkliche, FreeBSD 
eingeschlossen (siehe ARP-Problem in *-STABLE vor nicht zu langer Zeit). 
Debian sticht positiv hervor und erreicht Qualität durch Opferung von viel 
Zeit (weswegen in "aktuellen" Debian Releases häufig uralte Software ist, was 
man wiederum auch als Qualitätsmangel betrachten könnte, je nach Veranlagung)
-hinzu kommen soziale Probleme, welche bei den verschiedenen Projekten 
beobachtet werden können
-und so weiter und so weiter ...

Was schließen läßt, das sämtliche Sicherheitsprobleme (im weitesten Sinne, 
Softwareverteilung mit eingeschlossen) mit denen MS konfrontiert ist und die 
sich auch oder gerade aus der enormen Verbreitung von Windows ergeben in der 
OSS-Community ungelöst sind weswegen es bei einem umgekehrten Verhältnis (95% 
OSS und 5% Windows/Apple) keineswegs besser aussehen würde.

Ich möchte sogar soweit gehen und behaupten, daß die Spammer-Geschichten 
welche wir dann lesen könnten wesentlich vielfältiger und unterhaltsamer 
wären. Ganz zu schweigen von ungefixten Konqueror-Sicherheitslücken (Bugs, 
welche sich wegen der enormen Komplexität nur schwer fixen lassen sind 
sicherlich ein Grund für die langen Verzögerungen für Fixe bei MS und würden 
OSS genau so treffen, ähm treffen OSS genau so. Ich möchte an den letzten 
heap-overflow [an sich ein alter Hut und wohl bekannte Art von 
Sicherheitsproblemen] in OpenSSH erinnern [Wenn ich das richtig verstanden 
habe war er sehr schwierig zu finden auf Grund der in OpenSSH gegebenen 
Komplexität, wirkte also in Verbindung mit anderem code innerhalb openssh´s], 
in einer uralten Datei namens: buffer.c 
[Manch einer möge behaupten, daß schon der Name der Datei verdächtig ist und 
zu besonderer Vorsicht und Bedachtsamkeit mahnt, ein anderer möchte 
vielleicht die Frage nach der Wirksamkeit der auf OpenBSD beworbenen 
Code-Audits stellen, wieder andere mögen nach dem Wert von "open" fragen, 
wenn eine derartige Lücke in einer derart verdächtigen Datei derart lange 
unentdeckt bleibt.] Erinnert sei auch an Sendmail in der default Installation 
so mancher BSD's und Linuxe.).

Die mail ist lang genug drum strebe ich danach Sie mit folgenden Sätzen zu 
beenden:
Von der technischen Seite her geht es anders und das haben so manche schlauen 
Leute gezeigt, Code geschrieben und sogar Maschinen gebaut (zb. Lisp 
Maschinen, AXD 301, und andere). Ob das "andere" im realen Leben besser ist, 
läßt sich schwer sagen, so lange es da nicht genutzt wird (mal vom AXD 301 
abgesehen und mit Fokus auf den PC).

Ursprünglich war ich der Überzeugung, daß OpenSource gleichbedeutend ist mit 
ungebremster Innovationskraft welche zum Nutzen der Menschen wirksam wird. 
Ich sehe mich getäuscht und Stelle fest, daß Kompatibilitätsdrang, Trägheit 
("we always did it like that, there is no need to change") stärker sind als 
Innovationskraft. So manche gute Idee wurde in den verschiedenen 
Diskussionsforen in einem flammenden Inferno zu Asche verbrannt und kühlte 
danach schnell ab (manchmal auch aus sozialen Motiven heraus, zb. Positions- 
oder "Machterhalt", Soziale Mißverständlichkeiten führen zu einer 
Zersplitterung der Community [siehe zb. BSD-forks und deren Motivationen]). 
Ergo beschränkt sich Innovation zu häufig in hohem Maße auf die dem 
Opensource Programmierer naheliegenden ultra-technischen Dinge (z.b. Kernel, 
CORBA) welche weit weg vom eigentlichen potentiellen Nutzer (Nutzer, nicht 
Programmierer) sind welcher ganz legitime Motive haben mag, wie zum Beispiel 
kürzlich in dieser Liste zu lesen: "Ich mache Webdesign und nicht Linux."

Weiterhin konnte ich beobachten, daß sich die innovativen Leistungen (hier die 
wenigen revolutionären) von OSS letztlich aus der Kompetenz (umfassend, also 
sozial, organisatorisch, technisch, usw.) einzelner Individuen ergibt.

2003 wurde von Optimisten als das Jahr des Linux-Desktop angepriesen. Immerhin 
gute 2% hat Linux ja. So wird wohl 2004 das Jahr des Linux Desktop werden. 
Und wenn nicht 2004, dann 2005 oder 2006, spätestens dann wird www.xpde.com 
inklusive Registry Editor ( http://www.xpde.com/shots/regedit.png ) wirklich 
gut nutzbar sein. Moment, dann gibts ja schon wieder Longhorn ...
und kurz darauf Linuxhorn.org oder so und so weiter und so weiter ...
Der Nachahmungstrieb wird ersichtlich, die Innovation bleibt unsichtbar.

Ja, der Linux Netzwerk-Stack ist schneller als der von Windows. Aber wen zum 
Kuckuck interessiert das? 98% der Desktop-Nutzer ist das irgendwie egal 
scheint mir (zumal das Limit für die Allgemeinheit häufig vom ?DSL oder Kabel 
oder Modem oder dergleichen gesetzt wird, weit entfernt von Performance).

Huch, die mail wird immer länger ... 
... langsam muß ich wirklich Schluß machen :) und schließe endgültig mit 
folgenden Sätzen:
Also genug Kritik, mehr Lob und mehr Verbesserungsvorschläge hebe ich mir für 
später auf, eventuell gar zum Fortschritt hin wirkende Taten für viel 
später ..., ähm, behalte ich mir vor ;) 


  Gruß

  Jan Krüger
  Nordhalbkugler