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

[Jan Krueger]

On Sunday 26 October 2003 21:38, Steffen Dettmer wrote:
> Leider kommen vermutlich nur 10% der Anwender und 1% der
> Entscheidungsträger ebenfalls zu dieser Erkenntnis...
Wie ich im anderen Thread auch zu zeigen versuche bin ich der Auffassung, daß 
es nicht an den Anwendern liegt, IMHO.

> > Man nehme einen kleinen Micro- oder Nanokernel- (zB. L4, MIT
> > Exokernel o.ä.) Prozeß aus einem Execute in Place ROM-Bereich
> > und/oder spezielle Hardware welche folgendes tut:
>
> interessante Idee-Mail - fetzt ja :-)
Danke :)

> "Execute in Place ROM-Bereich" gibt es in Form von BIOS schon.
> Weil ROM so langsam ist, kam man dann zu Shadow :)
Ah, richtig. Haste Recht. Wenn ich mich erinnere so ist dies im Fall von ROM 
häufig nur langsam, weil ROM häufig (weil nicht so wichtig) aus kostengründen  
und wegen der sowieso geringen größe (256KB, das ist ja fast nix) schmal 
(1bit (zb. bei alpha), 8bit, 16 bit)  angebunden ist. OK, ROM bausteine sind 
langsamer so oder so, aber so viel langsamer als ram nicht. Oh, richtig, beim 
Amiga wurde ein nicht unerheblicher Teil des OS aus dem ROM heraus 
ausgeführt, damals, als 7.14 MHz noch schnell waren.

> > Code Segmente dürfen sich zur
> > Laufzeit nicht verändern.
> Kann man doch einfacher erreichen: es darf nicht in Code-Bereiche
> geschrieben werden, wie Du unten wohl meinst. Macht Sparc, glaub
> ich.
Meines (Halb-)Wissens nach optional, im gegensatz zu "immer, per default".
Also man kann es Anschalten, muß aber nicht. Ich glaub Solaris verzichtet 
darauf? Keiner Ahnung.

> Auch auf embedded hat man sowas öfter mal, auch wenn der
> Code ins RAM kopiert wird.  Weiß nicht, aber vielleicht kann das
> sogar ne Standard MMU von einem PC, benutzt vielleicht bloß
> keiner?
W^X, PaX
http://www.grsecurity.net/PaX-presentation_files/frame.htm
Hast Recht, macht keiner außer vielleicht OpenWall Linux.

>
> > -Code im Datenbereich kann nicht ausgeführt werden
>
> Macht Sparc auch, glaub ich. Dazu kommt noch: "Code im Stack draf
> nicht ausgeführt werden" (no-exec-Stack).
Beides ist häufig in Kombination anzutreffen und macht auch erst dann so 
richtig Sinn.

> > -besondere Hardwareunterstützung kann zb. durch physikalische Auftrennung
> > der Daten- und Code-Speicher erreicht werden
>
> Ja, muß ne MMU Funktion sein. Da die ja in die CPUs integriert
> sind (glaub ich), müßte das prima gehen.
Und funktioniert schonmal prächtig bei getrennten Daten- und 
Instructioncaches. Also geht im Prinzip.

> > Die besondere Eigenschaft des Code-Speichers ist, daß er sich
> > nur einmal durch das initiale Laden des Codes nach dem Starten
> > des Rechners beschreiben läßt
>
> Das ist ja blöd - dann kann man ja weder Programme nachladen oder
> entladen und braucht so unheimlich viel Speicher. Gut, kenne das
> vom Embedded-Bereich, aber für'n PC? Muß man dann bei Booten X,
> StarOffice und alle Mailprogramme schon mal laden...
Dabei dachte ich mehr an Server, also an Rechner die wohldefinierte Dienste 
über einen langen Zeitraum bereitstellen. bei einem Wuser Desktop ist das 
quatsch, klar.

> "Um das Mailprogramm starten zu können, legen Sie die SmartCard
> in einen Klasse-3 [das ist einer mit Display und Tastatur] ein".
>
> Der Anwender muß dann prüfen (wie?!), ob es das richtige Programm
> ist (secure hash?) - sonst könnte sich ja ein Trojaner über das
> Mailprogramm mitladen.
Im Falle eines OS/Anwendung könnte der Hersteller zum Beispiel eine Smartcard 
mitliefern auf welcher die entsprechenden secure hashes oder so bereits 
gespeichert sind, diese könnten dann von der Hardware irgendwie verglichen 
werden woraufhin das Laden des Codes freigegeben wird oder auch nicht.

> > Oder anders ausgedrückt: Diese Turingmaschine hat 2 Bänder,
> > eines für Code, zu Laufzeit read only, eines für Daten, wie
> > gehabt.
>
> Dann geht dynmisches Binden gar nicht mehr...
Jupp. Hat man gleich ein weiteres Problem, das mit den ständigen core-dumps 
wegen falscher Library Versionen, mit gelöst ;) Nachteil beim statischen 
binden wäre, daß so ein KDE binary richtig groß werden kann, also _richtig_ 
groß, und wen man dann mehrere davon hat ...

> Ich denke, es würde reichen, die Seiten im virtuellen Speicher
> eben typisiert zu verwalten: Code, Stack und Daten müßten dann
> eben grundsätzlich verschiedene Sachen sein. Der dyna-Lader ist
> dann ein (kernel-?) Prozeß. Wenn man das konsequent macht, kann
> ein User keinen eigenen Code mehr starten, nur noch systemweite
> Programme - damit kann ein User dann keinen Code mehr ändern und
> ausführen, nur noch "das System" (was auch immer das jetzt mal
> genau sein wird). Natürlich darf dann kein Dienstprogramm mit
> diesem hohen Berechtigungslevel arbeiten.
Das ist gut. Der user lädt den code nicht, sondern triggert lediglich das 
Laden des codes.

Es gibt Architekturen, welche auf einen Stack im Speicher ganz verzichten und 
dafür irgendwelche Register-Sachen verwenden, oder mehrere Counter oder so. 
Keine Ahnung, hab ich vergessen wie das funtkioniert.

> > -alternativ befindet sich Code grundsätzlich in einem (Flash-)ROM und ist
> > daher zur Laufzeit nicht manipulierbar und darf/kann auch nur in diesem
> > Bereich via Execute in Place ausgeführt werden.
>
> Wird langsam, oder?
Also mein PocketPC ist bei der Ausführung des Codes aus dem Flash-Rom heraus 
nicht wirklich langsam, nur ist ARM halt direkt für sowas designed und bewegt 
sich auch noch weit jenseits der Gigahertz-Grenze. Ich denke man könnte das 
technisch irgendwie lösen.

> > -Wenn man also dem System auszuführenden Code hinzufügen möchte, muß das
> > System in einen besonderen Installationsmodus versetzt werden, welcher
> > den Transfer von Code aus dem Datenbereich ind den (Flash-)ROM Bereich
> > erlaubt und nichts anderes.
>
> Also wieder mit z.B. SmartCard oder Schalter am Gehäuse, ja?
Hier meinte ich eher sowas wie Runlevel. Das System wird in den "Lade Code" 
runlevel gebootet, Das System lädt den definierten Code aus sicherer Quelle 
(zb. CD-ROM), daraufhin wird das System in den "execute code" runlevel 
versetzt und beginnt dann erst den Code auszuführen und Dienste anzubieten. 
Impliziert praktisch ein minimal zweitsystem, zb. realisiert durch firmware, 
welches das laden des codes übernimmt, also im "Lade Code" runlevel läuft.

Hm, hört sich irgendwie an wie die Funktionsweise eines Kernel bootloaders ...

> Na ja, dann mußte ja eben auf dem Klasse-3 Leser die Prüfsumme
> anzeigen, der Benutzer muß die in einer Liste der vertrauten
> Anwendungen nachsehen, um zu erkennen, ob jemand versucht,
> manipulierten Code zu laden. Du hast aber Recht, selbst wenn man
> das nicht macht, funktionieren gegenwärtige Cracks nicht mehr
> gut (glaub ich) - wenn es aber alle "haben" gibt's dann auch
> Cracks dafür :)
Weiß nicht, kann schon sein. Ist aber per gesetz verboten, hier oder da 
hinterm großen Teich, was aber die auf Pazifik-Insel X nicht interessiert...

> > -Wir brauchen alle mehr Speicher und/oder Flash-Speicher.
>
> Sowieso, oder? :)
Klar, 64bit Adressraum ist schon wieder fast Vergangenheit :)

> > -existierende Sicherheitsprobleme lassen sich ohne eine änderung der
> > architektur ( Software und/oder HW ) nicht lösen
>
> Es gibt solche Architekturen. Mit einer gut implementierten JVM
> z.B. sollte das schon nicht mehr gehen.
Daran glaub ich nicht so richtig, so lange die gut implementierte JVM in C(++) 
geschrieben ist und wegen Java an sich.

> Gleiches gilt für Ada und viele andere.
Jaja, es gibt schon schöne Sachen ...

> > -TCPAbla könnte obiges Checksumming Verfahren unterstützen? Keine Ahnung.
> > womöglich nicht. TCPAbla ist sinnlos?
>
> TCPA (oder wie das heißt) ist sogar mehr: der Code muß signiert
> sein, so daß man nicht alle Prüfsummen kennen muß - man kann dann
> ausrechnen, ob die stimmen. Für Hardware-Sicherheitsmodule eine
> gängige Praxis mindestens beim Update: lade nur signierten Code.
Nach dem der Code geladen ist tut TCPA ja nix mehr zur Sache, oder? und falls 
der Code nicht geschützt ist, freie Bahn BOFs.

Das bringt mich zu einer weiteren Verfeinerung: Code ist verschlüsselt im 
Speicher. Eine Kompromittierung des Verschlüsselten Codes durch Daten führt 
dann unweigerlich zu Code Müll und kann erkannt werden. Das wiederum setzt 
vorraus, daß das Key Management und das ganze drumherum irgendwie mit in die 
CPU müssen. Ah, da gibt es ja Ansätze in Form von zb. VIA C3 PadLock
welche allerdings eine DataEncryption Egnine ist, also noch weit entfernt vom 
Code. Müßte man eben mal kurz die Spezifikation lesen _und_ verstehen 
können... ich laß das lieber :)

> > Call for Investors:
> > Wenn jemand das nötige Geld sponsort implementier ich gerne einen derart
> > sicheren Rechner :)
>
> Du kannst sowas auch einkaufen, gibt's ja.
Wenn das weiter so geht werde ich durch die nicht gemachten BeLUG Patent 
Lizenzeinnahmen ja nie reich, dick, von Models umgarnt und Palmwedeln 
umwedelt, ...
"James, bitte fahr schon mal den RollsRoyce vor ... Ach nein, doch lieber den 
F40" ...

So ein Glück aber auch :)

> Wird vermutlich teuer
Egal, so lange teuere Militär-Technik gebaut wird um zu Staub zerballert zu 
werden gibts sicherlich einen der genau das glaubt zu brauchen und teuer geld 
dafür bezahlen möchte.

Auf den warte ich jetzt :)

Dann verzichte ich auf reich, dick, Palmwedel, Autos, behalte die Models und 
verwickle sie in langwierige intellektuelle Gespräche :)

Gruß
Jan