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

Jan Krueger jk at microgalaxy.net
Mi Okt 29 18:16:10 CET 2003


On Monday 27 October 2003 03:56, Peter Ross wrote:
> Sicherheit ist endlich. Wetten, auch Deine Idee hat einen Haken?
Klar, einen Widerhaken :)

> > > - 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.
> ?? Jedes System ist von einem Administrator abhaengig.
Ja, stimmt schon. Was ist wenn Du Oracle oder andere closed source Produkte 
unter OpenBSD betreiben möchtest? Dann kannst Du W^X nicht auf diese 
enforcen. Mit Linux W^X schon.

> > W^X kann nicht schützen was z.b. innerhalb einer VM
> > abläuft (Java, Erlang) und Auswirkungen auf das System haben kann.
>
> Ja. Da sind dann die Sprachen gefragt.
Eben. Und warum nicht gleich geeignete, sichere Sprachen einsetzten?

> > [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.]
> Also, ich glaube Dir, dass da ein hochverfuegbares Produkt existiert, die
> exakte Zahl duerfte aber witzlos sein. Marketing halt.
Klar, Marketing. SO wie ich das verstanden wird dieser switch (der 
Telefonverbindungen über ATM switched) aufgebaut, läuft 20 Jahre durch, und 
wird dann ersetzt durch einen neuen. 20 Jahre ist tatsächlich die Expected 
Product Life Time.



> > > - grsecurity, chflags, capabilities, acl, RSBAC, IDS, *-Scanner,
> > > *-Filter, Firewalls ...
> >
> > ... fügen einem System ein hohes Maß an Komplexität hinzu.
>
> Die Dinge, die _ich_ einsetze, kann ich ueberschauen (deshalb z.B. keine
> Windows-Systeme, wenn's geht;-)
Also obige erwähnte Technologien sind durchaus zukünfitg einsetzbar nur fehlem 
im Moment die entsprechende Werkzeuge, welche es dem Menschen ermöglichen 
diese Komplexität zu beherrschen. Es ist auch nicht erkennbar, daß sich das 
demächst ändern wird im Open source bereich, weshalb eben diese Technologien 
durchaus skeptisch zu betrachten sind.

> Auf Serversystemen braucht man in der Regel keine ACLs, da die Menge der
> Dienste und Nutzer ueberschaubar sind und das einfache
> User/Group/World-Konzept voellig ausreicht.
>
> > über den Sinn und Unsinn von chflags kann man sich streiten. Es ist
> > paktisch um sich als root vor Dummheiten zu schützen.
>
> Mehr.
>
> Es ist dazu da, dass ich, auch wenn ich auf einem System root-Rechte
> erlangt habe, keine Files austauschen kann (verhindert die beliebten
> Rootkits), und keine Logfile-Eintrage geloescht werden koennen, um Spuren
> zu verwischen (wenn die Flags nur ein Anhaengen erlauben)
>
> Darueber lass ich nicht mit mir streiten;-) Es _ist_ eine sinnvolle
> Sicherheitsmassnahme.
Ja, um sich als root vor Dummheiten zu schützen ;)



> Nein, siehe chflags-Beispiel. Es sind die Huellen einer Zwiebel, durch die
> Du durch musst.
Wenn man was erreichen will?

Wenn ich root werden möchte auf einem Zwiebel-Rechner, dann ja.
Daß es schwierig ist root zu werden, einfach so aus dem Netz heraus, weiß 
jeder Hacker (es sei denn, auf dem Rechner ist sendmail installiert).
Drum will es keiner. Spammer brauchen Proxies um ihre Bandbreite und ihren 
Wirkungsradius zu erhöhen. Da reicht ein Apache mit Sicherheitslücke 
vollkommen aus. Andere Hacker wollen einfach an die Nutzdate ran. Bei einem 
einfachen e-commerce System kann es zb. PHP im Apche sein, dem Zugriff auf 
bestimmte Kundendaten (Web-Login-Passworter) gewährt wird - und wieder reicht 
ein Loch in PHP oder APache aus da heran zu kommen.
Online-Banking, Berliner-SParkasse, noch zu Ihren Anfangszeiten, wenn man eine 
Kontonummer eingegeben hat und _keine_ PIN und sich so eingeloggt hat, wurde 
einem ein Zufälliges Konto präsentiert in welchem man wirtschaften konnte, 
zum Glück ohne Transaktionen auslösen zu können, weil dafür ja TANs benötigt 
werden.

> Beispiel apache im Jail als Nutzer www laufen:
>
> Bin drin, als Nutzer www. Ich kann innerhalb des Jails alles das aendern,
> was der Nutzer www aendern kann. Du bist aber immer noch im jail und hast
> auch hier keine Rootrechte.
Die will ja auch keiner haben. Das ist nicht mehr interessant. Früher, als die 
Systeme klein waren und sich alles irgendwie um root gedreht hat, ja, da war 
das interessant. Aber heutzutage, wen interessiert schon was Du als root in 
Deinem /root hast? Die Ziele sind mißbrauch von ressourcen und zugriff auf 
nutzdaten. Für beides ist root nicht erforderlich.

> Schaffst Du das jail, bist auf dem Hostsystem gelandet und root geworden,
> kannst Du immer noch Dein Rootkit installieren, dazu ist Dir chflags im
> Wege.
>
> Du hast einen Server installieren koennen? Schoen, aber Du kannst ihn
> nicht erreichen, weil der Paketfilter alle Pakete abfaengt..
Alle? Wirklich alle?
Wie reagiert der Paketfilter auf handgearbeitete Pakte welche das Wissen der 
über die Netzstruktur und damit wissen über die Konfiguration des 
Paketfilters ausnutzen? Wie ist es mit DNS?

> > 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.
>
> Sicher, nur wer sich nicht bewegt, macht keine Fehler - alte Weissheit
> eines erfahrenen Bueromikadospielers. ("Wer sich zu erst bewegt, ist
> draussen.")
Ja, stimmt auch wieder.

> > Warum ist es nicht einfach sicher?
>
> Nur der Tod ist sicher.
Sicher?

>
> Ich habe eine Blume neben mir.. die ist vor Dir ziemlich sicher. Sie ist
> ein paar Tausend Kilometer von Dir entfernt, Du hast meine Adresse nicht,
> und auch keinen Haustuerschluessel.
>
> Ja, Du kannst meine Adresse finden, ein Ticket kaufen und die Scheibe
> einschlagen. Und?
> [...]
> Wie, der Aufwand ist Dir zu hoch? Ja, so ist es auch im Computerleben.
Hihi, ich wäre anders vorgegangen. Hätte ich Deine Adresse, hätte ich auch die 
Adresse Deines Nachbarn. Den hätte ich einfach angerufen und ihn gefragt ob 
er dich gut leiden kann, weil ich Dich überraschen wollte. Und je nach dem 
wie er geantworted hätte hätte ich darauf eingestellt und ihn die Blume 
entsorgen lassen, entweder friedlich oder hinterhältig :)

Und das mit dem Tresor hätte ich auch irgendwie gelöst, ganz sicher :)
Du hast ja bestimmt noch mehr nachbarn die auch was schweres tragen können, 
oder? Und bevor ich der Fluggesellschaft tausende in Rachen stecke und der 
Umwelt schade unterstütze ich lieber eure community :)

> > Genau. Nicht der Nutzer ist falsch, sondern die Technologie, wenn das
> > System, wenn es sicher sein soll, 2 Jahre zum booten braucht.
>
> Nein, nicht zum Booten. Das geht selbst bei gutgesicherten Systemen
> schneller als den meisten Generic-Kerneln der gaengigen Linux-Distros;-)
Was aber nicht an dem Kernel liegt, sondern an diesem Sys V Init Bloat. Habe 
neulich ein Apple PowerBook 170 repariert, 25 MHz, 8 MB Ram, 20 MB Platte 
oder so. Hat in 53 sekunden gebootet und MS Word startete in 7 Sekunden, also 
exakt eine Minute bis man loslegen kann. Und Linux? Egal welche 
Desktop-Distri man wählt und egal wie schnell der Rechner ist bei diesem 
boot-benchmark hätte der Apple die Nase vorn.

> > 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:
> > ..
>
> Lass mal gut sein, ich freue mich auch ueber so manche "Entwicklung".
Ja, ich doch auch.

> > 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.
>
> Nicht ganz. Es gibt graduelle und konzeptionelle Unterschiede. Die von mir
> genannten Sicherheitsmassnahmen sind auf Windows-Buechsen kaum anwendbar
> und ich kenne keine gleichwertigen.
Sind sie doch, man kann Windows-Büchsen derart absichern, gibt es alles, 
Winsows ist auch nur ein (stark modifiziertes) Unix. Dauert halt länger und 
man muß ganz schön rumwühlen.

> > 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.
>
> Nein. Auf MS-Desktops sind haufenweise Nutzer als "Administrator"
> eingeloggt. Du kannst bei geknacktem IE das ganze System austauschen und
> beliebige Server installieren.
>
> Auf einem Desktop-Linux out of the box kann ein Konqueror-Bug noch keine
> Rootkits installieren (hoffe ich mal, oder laeuft der als Root?) und auch
> keine Server auf prviligierten Ports, gewoehnlich unter 1024, starten.
Wozu auch. Ob der Proxy nun an Port 80 oder 8080 lauscht ist egal. und ob er 
al root läuft oder als kdeinit-prozeß ist auch egal. s.o.

> > Der Nachahmungstrieb wird ersichtlich, die Innovation bleibt unsichtbar.
>
> Unix, BSD, Mach etc. sind innovative Projekte, die zunaechst der Forschung
> dienten und dann in "nutzbare" Systeme umgesetzt wurden (auch in Windows
> steckt so manches davon), den innovativen Teil des Linux-Projektes sehe
> ich kaum.
Sag ich doch. Ist ja auch als Eeimplementation der vorhandenen Ideen 
gestarted. Reiser4 könnte man als innovativ betrachten, vielleicht alsa

> Allerdings waere mir gelegentlich schon wohler, nicht immer mit Windows zu
> tun zu haben, das ist wirklich ein System,. bei dem administrieren keinen
> Spass macht und ausserdem ist es langweilig, alle Tage Mail vom
> MS-Update-Center zu bekommen;-)
:)

> Insofern begruesse ich den Marsch von Linux-Systemen auf den Schreibtisch.
Der nicht stattfindet, weil die OSS Community Probleme welche MS gelöst hat 
oder dabei ist zu lösen bisher versäumt hat zu erkennen, geschweige denn zu 
lösen.

Gruß
Jan





Mehr Informationen über die Mailingliste linux-l