Automata Toolbox - Sicherheit

Hacker

Das Programm ist durch das Mail-Interface für jedermann verfügbar. (Es wäre denkbar, nur Einsendungen von *.uni-leipzig.de zu akzeptieren, aber viele Studenten möchten sicher ihre private Mailadresse verwenden.) Damit ist es ein potentieller Angreifpunkt für Hacker. Ich denke aber, die verwendeten Scripte sind so sicher, daß keine Files im System geändert werden (außer denen in autotools/work) und keinerlei Fileinhalte nach außen gelangen können (etwa /etc/passwd). Die einzige Stelle, wo der Einsender einen Filenamen angibt, ist das Subject, aber dort wird durch procmail getestet, daß keine Punkte oder Slashes enthalten sind.

(Siehe auch weiter unten zu IO-Aktionen.)

Identifizierung

Falls Einsendungen bewertet werden sollen, muß die Identität des Absenders festgestellt werden. Das erfolgt im einfachsten Fall über die Absenderadresse der Mail (an die geht auch die Antwort). Dazu müssen mir die Studenten am Anfang des Semesters ihre Mailadresse bekanntgeben (das tun sie bereits bei der WWW-Einschreibung)

Das hat folgende Schwachpunkte:

Abstraktionen

Ich muß sichergehen, daß der Student die Aufgabe wirklich ausschließlich mit den geforderten Hilfsmitteln löst. Wenn beispielsweise eine Maschine gefordert ist, die nur nach rechts läuft, dann darf er gar keine Gelegenheit haben, das Links-Laufen in der Übergangstabelle zu benutzen. Das erreicht man durch geeignete Wahl der Modul-Interfaces (nur wenige Typen sollen exportiert werden, und kaum welche mit sichtbaren Konstruktoren). Es ist eine interessante Frage, inwieweit Haskell dieses Anliegen unterstützt.

IO-Aktionen

Die strenge referentielle Transparenz von Haskell ist dabei eine große Hilfe. Stellen wir uns vor, alles wäre C. Da der Student ein Programm einschickt, das vom Server (kompiliert und) ausgeführt wird, ist das ein weiterer Angriffspunkt für Hacker: das Programm könnte unbefugt Files löschen oder lesen.

Nun geht das in Haskell nicht, denn IO-Aktionen stecken in der IO-Monade, und aus der kommen sie nicht "raus". Das heißt: ich verlange (durch den vorgebauten Header, siehe autotool in Implementierung), daß das Modul des Studenten einen Wert vom Typ Turingmaschine (beispielsweise) exportiert, und um diesen zu erzeugen, dürfen schon aus Typ-Gründen keine IO-Aktionen stattfinden.

Das ist an einer Stelle angreifbar: es gibt das (Nicht-Standard-)Modul IOExts mit der "Funktion"

unsafePerformIO :: IO a -> a
und damit kann man dann doch beliebig zaubern. Das kann ich aber unterbinden, indem ich überhaupt alle import-Deklarationen im Studentenprogramm verbiete.

Nun könnte jemand kommen und gerne import List(partition) sagen wollen. Das will ich ja gar nicht verbieten. Besser wäre, eine Version von hugs/runhugs zu benutzen, die alles kann, aber IOExts nicht (indem das File einfach aus share/hugs/libs/exts gelöscht wird).


best viewed with any browser


http://www.informatik.uni-leipzig.de/~joe/ mailto:joe@informatik.uni-leipzig.de