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:
- Eine Änderung der Adresse während des
Semesters ist umständlich (aber machbar).
- Es können nicht zwei Leute die gleiche Absenderadresse benutzen
(Es ist evtl. sogar wünschenswert, das zu verhindern?)
- Wer weiß, wie es geht, kann das Absenderfeld einer Mail
leicht fälschen, und dadurch jemand anderem zu Punkten verhelfen
(sich selbst jedoch nicht).
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).
http://www.informatik.uni-leipzig.de/~joe/
mailto:joe@informatik.uni-leipzig.de