|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
|
Endlich wird diese eigentlich einfache Regel
von jemandem implementiert. Kontrollieren,
was vom Kernel als ausführbar gilt.
Die von-Neumann Architektur mit Daten
und Programmen im gleichen Speicher ist
genial simpel, aber hat halt eben
unter dem Gesichtspunkt der IT-Security
entscheidende Schwächen.
Diese Idee sollte IMHO auch für das
Design der 'next generation'
Benutzer-Oberfläche/OS benutzt werden: Der Benutzer
weiss bei jedem Click, ob er nun etwas
ausführt oder nur Daten in ein bereits
laufendes Programm überträgt.
Solange eine Datei nur auf der Disk
liegt, kann sie keinen Schaden anrichten,
auch wenn es der Code zu Melissa ist.
Ein .EXE kann auf einem Linux-Rechner kein
Problem sein, weil es keinen 'Interpreter'
oder 'Loader' dafür gibt (oh - wie war
das mit DOSEMU und WINE ?)
Es ist also nicht die Datei, die
gefährlich ist, sondern erst die Umgebung
('der Wirt') kann eine Datei in etwas
gefährliches umwandeln (d.h. von einer
Datei zu einem Prozess machen).
Ich glaube, einen Fortschritt in der
IT-Sicherheit erreichen wir erst, wenn
auf einer Plattform nur
Formate verwendet werden, die
entweder Daten oder
ausführbaren Code enthalten und dem
Benutzer dieses Konzept klar ist.
Keine aktiven Inhalte in Daten!
Gebt dem User die volle Kontrolle!
maNic
PS: Ich weiss, das Konzept ist noch
nicht ganz durchdacht, aber wäre das
nicht wenigstens die richtige Richtung?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> Ich glaube, einen Fortschritt in der IT-Sicherheit erreichen wir erst,
> wenn auf einer Plattform nur Formate verwendet werden, die entweder Daten
> oder ausführbaren Code enthalten und dem Benutzer dieses Konzept klar ist.
Vermutlich spielst du damit auf die Microsoftschen OLE-Container und andere Compound-Formate an. Du hast natürlich recht, dass das Problem der Macro-Viren eigentlich nur mit undurchsichtigen Monstern wie .doc oder .xls ein wirkliches Problem wird.
Aber das Problem dabei ist die Intransparenz, nicht die Dualität von Daten und Code. Zum Beispiel bietet das
Speicherkonzept von OpenOffice den selben Komfort wie MS-Office, aber in einer zugänglichen Form, nämlich getrennte XML-Dateien in einer umhüllenden ZIP-Datei.
> [...] Keine aktiven Inhalte in Daten!
$ cat /etc/sysconfig/mouse
MOUSETYPE="ps/2"
XMOUSETYPE="PS/2"
FULLNAME="Generic Mouse (PS/2)"
XEMU3=yes
DEVICE=/dev/mouse
Frage: Sind das jetzt Daten oder ist das Code?
Zur weiteren Verwirrung noch etwas Information:
$ ls -l /etc/sysconfig/mouse
-rw-r--r-- 1 root root 95 Dec 13 13:24 /etc/sysconfig/mouse
Antwort: Sowohl als auch.
Die Init-Scripts von Red Hat lesen die Daten mit ". /etc/sysconfig/mouse" ein (und brauchen deswegen kein Executable-Bit). Für GUI-Konfigurationstools wie mouseconfig ist das Format aber trivial zu lesen und zu schreiben. Und dabei ist dieser Fall noch harmlos gegen /etc/crontab oder
/etc/inittab.
IMHO liegt in der Fähigkeit der iterativen Generierung und Interpretation von Code und Daten die Stärke der Von-Neumann-Architektur. Und IMHO was das auch nie ein Problem, solange die Vorgänge kontrollierbar und nachvollziehbar waren.
In der Geschichte von Unix ist mir nur ein Beispiel bekannt, wo dem Anwender diese Kontrolle mutwillig entzogen wurde: shar
--
Ich bin ein Teletubby. Und das ist auch gut so.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vielleicht sollte man ein System einführen wie bei Ruby: Objekte, die von einer unsicheren (tainted) Quelle stammen, sind selber auch als tainted markiert. Strings, die z.B. per gets eingelesen werden, dürfen dann nicht "eval"uated werden. Naja, klar, das ganze in einem kompletten System aufzurüsten ist aufwandmässig kaum zu vertreten.
Das Problem ist, wie du gesagt hast, dass die Grenze zwischen Code und Daten kaum definiert werden kann. Und ich denke nicht, dass die Separation im RAM etwas bringt, wenn sie dann doch auf der selben Festplatte liegen. Vielleicht würde es etwas brinen, Dateien als Daten oder Programme zu deklarieren (einfach) und vom Betriebssystem aus zu entscheiden, wohin im RAM die Teile gehören. Aber das würde AFAIK die ganze bestehende Struktur umkrempeln, da man so ziemlich jedes Programm ändern müsste.
tL
--
Keine Angst vor M$-Saftware! Ungeladen ist sie völlig harmlos.
|
|
|
|
|
|
|
|
|
|
|
|
|
Objekte, die von einer unsicheren (tainted) Quelle stammen, sind selber auch als tainted markiert. Strings, die z.B. per gets eingelesen werden, dürfen dann nicht "eval"uated werden.
Gibt's in PERL auch: Einfach "perl -T" statt "perl" verwendet. Und schon dürfen "verseuchte" Variablen nicht mehr für system, exec, open, etc. verwendet werden. Dekontaminieren kann man IIRC nur mit m// + $<n> oder s///, da das tainted-Flag am Wert und nicht der Variablen hängt. Sollte man eigentlich in jedem suid- oder CGI-PERL-Skript machen, genauso wie "-w"...
--
Einer der Gnutella-Klone heißt Gnutoka, und ich frag mich, wann Gnusspli rauskommt...
|
|
|
|
|
|
