Sicherheitsimplikationen beim Einsatz von Test Doubles zur automatisierten Bewertung studentischer Java-Programme mit Graja und mockitoRobertGarmannrobert.garmann@hs-hannover.deFakultät IV -Wirtschaft und Informatik Ricklinger StadtwegHochschule Hannover120, 30459HannoverSicherheitsimplikationen beim Einsatz von Test Doubles zur automatisierten Bewertung studentischer Java-Programme mit Graja und mockitoD3CD07E7F80A72E132B709E436FED94AGROBID - A machine learning software for extracting information from scholarly documents
Wir demonstrieren, dass der Einsatz von Test Doubles bei der automatisierten Bewertung studentischer Java-Programme besondere Sicherheitsfragen aufwirft. Wie skizzieren kurz eine mögliche Antwort auf diese Fragen.
Im ersten Teil demonstrieren wir die Erstellung eines sog. AssignmentGraders, der in der Lage ist, interne Programmschnittstellen eines maschinell zu bewertenden Java-Programms zu beobachten. Beispielhaft nutzen wir den Autobewerter Graja in Verbindung mit mockito Test Doubles. Wir zeigen, wie man Leistungsaspekte einer studentischen Lösung einzeln und gezielt automatisiert bewertet. Bei einer Beschränkung auf die Beobachtung externer Programmschnittstellen würden sich diese Aspekte der gezielten Bewertung entziehen. Im zweiten Teil beleuchten wir Bedrohungen des das zu bewertende Programm ausführenden Systems und gewichten ausgewählte Ursachen. Wir konzentrieren uns auf Bedrohungen, die mit Mitteln der Java-2-Sicherheitsarchitektur beherrschbar sind und liefern einige Beispiele zur Abgrenzung. Die Eigenheiten der Java-2-Sicherheitsarchitektur werfen im Kontext des Test Double Einsatzes Fragen auf, die wir im dritten Teil erörtern. Test Doubles sollten in einem anderen Schutzbereich der Java-2-Sicherheitsarchitektur als der studentische Code liegen. Um eine privilegierte Ausführung der Test Doubles auch dann zu forcieren, wenn der Aufruf aus studentischem Code erfolgt, schlagen wir den Einsatz von Proxy-Objekten vor. Um auch Nicht-Spezialisten der beschriebenen Sicherheitsbelange die Autorenschaft von AssignmentGradern zu ermöglichen, entwickeln wir eine Wrapper-Bibliothek für mockito, deren zentrale Entwurfsideen wir kurz skizzieren.
Einleitung
Automatisierte Bewertung studentischer Programme wird in der Informatik-Lehre zurzeit überwiegend im formativen Assessment eingesetzt. Zeit-und ortsunabhängiges, maschinell erstelltes, quantitatives und qualitatives Feedback soll Studierende in die Lage versetzen, ihre (Teil-)lösungen zu Programmierübungen schrittweise zu verbessern.
Studentische Programme müssen funktionale und nichtfunktionale Anforderungen erfüllen, die mit statischen oder dynamischen Analyseverfahren untersucht werden können. Für die Analyse der "inneren Qualität" des Bewertungsobjekts spielt die dynamische Analyse an internen Programmschnittstellen (Methodenaufruf) eine wichtige Rolle. Unittest-Frameworks wie JUnit wurden dazu entwickelt, kleinste Einheiten eines Testobjekts durch Methodenaufruf und Verifizierung des Ergebnisses dynamisch zu untersuchen. Um die zu untersuchende Einheit für die Dauer des Tests vom Restsystem zu isolieren werden Test Doubles einge-setzt, die z. B. mittels der Bibliothek mockito [Ka13] erstellt werden. An einer Beispielaufgabe verdeutlichen wir in Abschnitt 2, wie der JUnit-basierte Autobewerter Graja und mockito zur Beobachtung interner Programmschnittstellen genutzt werden können.
Das studentische Programm wird bei der dynamischen Analyse ausgeführt. Sicherheitsmaßnahmen auf dem Bewertungsrechner sind notwendig, um ungewolltes oder böswilliges Fehlverhalten des studentischen Programms zu unterbinden. In Abschnitt 3 stellen wir das betrachtete Modell eines Bewertungssystems vor und diskutieren relevante Sicherheitsaspekte.
Bibliotheken wie mockito wurden nicht für die automatisierte Programmbewertung entworfen. Die Sicherheit der Testumgebung spielt beim (Regressions-)Test großer Softwaresysteme meist eine untergeordnete Rolle. Im Bewertungsszenario jedoch wirft der Einsatz einer solchen Bibliothek essentielle Sicherheitsfragen auf, für die wir in Abschnitt 4 eine mögliche Lösung vorstellen.
Beobachtung programminterner Schnittstellen
Die Frage, wann ein studentisches Programm gut ist, ist nicht leicht zu beantworten. Neben dem Kriterium der funktionalen Korrektheit muss das Programm nichtfunktionale Kriterien erfüllen (Effizienz, Änderbarkeit, …). Einige dieser Kriterien lassen sich recht gut automatisiert untersuchen. Grundsätzlich gibt es zwei Herangehensweisen bei der maschinellen Untersuchung eines Bewertungsobjektes [SL05]: die statische Code-Analyse (bspw. in [SBG10]) und die dynamische Code-Analyse (bspw. in [KSZ02], [Ed03]). In diesem Aufsatz befassen wir uns mit der letztgenannten Herangehensweise, der Beobachtung des Verhaltens eines studentischen Java-Programms durch Tests.
Graja
Beispielaufgabe
Bedrohungspotential
Bedrohungen im Einflussbereich des Java Securitymanagers
Uns interessieren ganz allgemein alle Bedrohungen der Vertraulichkeit und Integrität der Daten auf dem die JVM beherbergenden System (Dateien, Nutzerdaten, Musterlösungen, …), sowie alle Bedrohungen der Verfügbarkeit des Bewertungsdienstes. Wir wollen mit der Bedrohungsanalyse dieses Kapitels keine konkret auszumerzenden Schwachstellen identifizieren, sondern es soll hier darum gehen, einige mögliche Angriffe mit ihren Auswirkungen ("impacts") zu benennen, die genügend Motivation liefern, um den Einsatz des Java Securitymanagers für sinnvoll zu erachten. In der folgenden Darstellung nehmen wir die zu motivierende Maßnahme vorweg: den Einsatz des Securitymanagers. Die Motivation der Maßnahme durch Angriffsbeispiele folgt in Abschnitt 3.4.2.
Einsatz der Java Sicherheitsarchitektur
"rm -rf /"
Ein bösartiges Beispiel für Submission-Code, welcher versucht, alle Dateien im Dateisystem zu löschen:
Runtime.getRuntime().exec("rm -rf /");
Durch Gewährung selektiver Dateizugriffsrechte mittels der Java Sicherheitsarchitektur oder auch mittels der vom Betriebssystem verwalteten Dateirechte kann dieser Angriff gut abgewehrt werden.
Denial of service
Ein anderes Beispiel, das versucht Schaden anzurichten, in dem es die Festplatte füllt 10 :
FileOutputStream f=new FileOutputStream("x"); while (true) f.write(42);
"/etc/passwd"
Es folgt ein Beispiel, das versucht, die Liste der Benutzernamen des Systems auszuspähen:
Da die Datei /etc/passwd i. d. R. für jeden Systemnutzer lesbar ist, können vom Betriebssystem verwaltete Dateirechte nicht greifen. Dies ist eine Bedrohung, die durch selektive Rechte gemäß der Java Sicherheitsarchitektur abwehrbar ist.
Ausspähen der Musterlösung
Ist etwa der Klassenname einer Musterlösung, die häufig Teil der AssignmentGrader-Komponente ist, bekannt oder erraten worden, könnte man wie folgt versuchen, an den Bytecode der Musterlösung zu kommen:
InputStream is= Class.forName("org.domain.sample.Solution"). getResourceAsStream("Solution.class"); int b; while ((b= is.read()) >= 0) System.out.print(b+" ");
Die Standardausgabe wird dem Autor der Submission i. d. R. zur Erläuterung der Bewertung angezeigt.
Dieser
Angriff ist leicht mit Mitteln der Java Sicherheitsarchitektur abwehrbar, indem das Recht zum Einlesen des AssignmentGrader-jar-Archivs nicht gewährt wird.
Ausführen der Musterlösung
Die Submission könnte versuchen, die Musterlösung einfach auszuführen und dadurch die generierten Ausgaben als die eigenen zu "verkaufen". Dieser Angriff lässt sich abwehren, indem die Musterlösungsklasse als package private deklariert wird und indem Submission-Code das Recht zur Überwindung der Package-Kapselung nicht erhält. 10 Bei diesem Beispiel kann es sich auch um eine unabsichtlich herbeigeführte Bedrohung handeln.
Wirkung der Schutzbereiche zur Laufzeit
Die drei in Abschnitt 3.1 eingeführten Schutzbereiche werden üblicherweise der Klasse der Anwendungsbereiche (application domains) zugeordnet. Ein vierter Schutzbereich mit i. d. R. uneingeschränkten Rechten ist der Systembereich (system domain), dem u. a. die Klassen der Java-Standardbibliothek angehören.
Bei eingeschaltetem Securitymanager prüft die JVM zur Laufzeit alle an der aktuell aufzurufenden Operation beteiligten Komponenten auf dem Aufrufstapel. Entwurfsidee 3: Für weitere Klassen der mockito-Bibliothek werden nun (einfachere) Wrapper geschrieben werden. Bspw. besitzt OngoingStubbingWrap<T> ein Instanzattribut vom Originaltyp OngoingStubbing<T>. Methodenaufrufe wie thenReturn werden an das Instanzattribut delegiert. Rückgabewerte werden wieder in Objekte der …Wrap-Klasse eingehüllt.
Zentrale Entwurfsideen von Mockito-Wrap
Fazit
Abbildung 5: Drei geladene Komponenten3.2 Benötigte RechteDer AutograderCore benötigt für seine Funktion weitgehende Rechte (Zugriffe auf das lokale Dateisystem, Ausführen des Compilers, Verwendung eigener Klassenlader, Zugriff auf Reflection-Funktionen, etc.). Die Submission benötigt in der Regel wenige Rechte, wobei dies sicher von der Art der zu lösenden Programmieraufgabe abhängt. Dazwischen im Sinne der Rechtemenge steht der AssignmentGrader, der häufig grundlegende Rechte für Dateizugriffe, manchmal auch weitergehende Rechte besitzen muss. Eine Teilmengenbeziehung zwischen den benötigten Rechtemengen der drei genannten Schutzbereiche besteht nicht notwendigerweise.von AssignmentGradern wird die Sicherheit des Autobewerters so wichtig sein, dass sie die Mühe auf sich nehmen und eine Klasse Proxy<T> für jeden zu doublenden Typ T programmieren wollen. Es handelt sich zudem um höchst spezialisierten Code, der ein tiefes Verständnis von Java Reflection und Generics erfordert.Die naheliegende Idee ist nun, die Erzeugung der Proxy-Objekte in eine Bibliothek auszulagern, die dem AssignmentGrader-Schutzbereich angehört. Wir stellen im folgenden Abschnitt kurz die Entwurfsideen einer neuen Bibliothek MockitoWrap als Hülle um mockito vor, die sich um die Erzeugung von Proxy-Objekten kümmert, welche Aufrufe an Test Doubles delegiert, wobei jeder delegierte Aufruf in ein doPrivileged-Konstrukt "verpackt" ist.Wählt man wie in Graja JUnit-Tests als Werkzeug zur automatisierten Programmbewertung, ist der Einsatz einer Bibliothek zur Erzeugung von Test Doubles naheliegend. Studentischer Code und Test Doubles gehören verschiedenen Schutzbereichen an. Test Doubles sind im Aufrufbaum Kinder des studentischen Codes, so dass tendenziell restriktive Rechte des studentischen Codes an Test Doubles vererbt werden. Mock-Bibliotheken benötigen für ihre Test Doubles jedoch Rechte von erheblichem Bedrohungspotential. Um den von der Lehrkraft geschriebenen Bewertungscode nicht mit sicherheitsspezifischen Details (Proxy-Objekte mit in doPrivileged-Aufrufen gekapselten Delegationen) zu "verschmutzen", bietet sich die Verlagerung dieser Details in die Mock-Bibliothek oder in einen hierfür zu schreibenden Adapter an. Die Erstellung eines solchen Adapters kann durch Nutzung von Java Generics und der Java-Reflection-Bibliothek kompakt gelingen.
Benutzer des studentischen Programms bedient werden können. Um ein Bewertungsobjekt nun automatisiert mit Eingaben über die genannten Schnittstellen zu versorgen und die Ausgaben maschinell auszuwerten, werden Autobewerter wie der hier eingesetzte Graja[St13] verwendet. Ein automatisiertes Bewertungsverfahren nimmt bei Nutzung der oben genannten Schnittstellen das Bewertungsobjekt als "black box" wahr und kann wenig über die Qualität der inneren Struktur des Bewertungsobjekts erfahren. Gut überprüfbar ist die funktionale Korrektheit und die Überprüfung einiger nichtfunktionaler Eigenschaften (z. B. Ressourcenverbrauch). Um mehr über die "innere Qualität" des Bewertungsobjekts zu erfahren, ist es hilfreich, das studentische Programm an internen Programmschnittstellen zu beobachten. Eine geeignete Schnittstelle ist der Methodenaufruf mit Methodenparametern als Eingabe und Methodenrückgabe als Ausgabe. Im Folgenden geben wir einen kurzen Überblick über die Funktionen von Graja und stellen eine Beispielaufgabe vor. Danach zeigen wir, wie studentische Lösungsversuche für diese Aufgabe mit Graja unter Einsatz von Test Doubles bewertet werden können.
Bei der dynamischen Code-Analyse beobachtet man dasLaufzeitverhalten des Bewertungsobjekts an beobachtbarenSchnittstellen. Hervorragend geeignet für die Überprüfung derfunktionalen Korrektheit des Bewertungsobjekts sind Ein-undAusgabeschnittstellen des Benutzers, die auch leicht einermaschinellen Bedienung bzw. Abfrage zugänglich sind.Interessante Schnittstellen für die Bewertung des studentischenProgrammverhaltens sind u. a. 1 Tastatureingabe, Consolenaus-gabe, Mauseingabe, GUI-Ausgabe [TE08], Kommandozeilen-argumente beim Programmstart, Dateiein-/-ausgabe. Allengenannten Schnittstellen gemein ist, dass sie prinzipiell auch vom
Graja ("Grading Java programs") ist i. w. ein Überbau über dem JUnit 2 -Testframework und hat seine Charakterzüge von seinem Vorbild WebCAT[Ed03] geerbt. Graja bietet u. a. folgende Funktionen:
Extrahieren und Übersetzen von Code aus einem ZIP-Archiv, Umleitung von Standard-Ein/Ausgabeströmen zur Verein-fachung der maschinellen Steuerung des Bewertungsobjekts, intelligente Vergleiche von erwarteter und beobachteter Aus-gabe eines Bewertungsobjekts, bequeme "reflection"-basierte Analyse studentischen Codes, Generierung formatierter, zielgruppenorientierter, und nachKritikalität abgestufter Bewertungskommentare, abgestufte Punktevergabe für verschiedene vom Dozentenfestzulegende Bewertungsaspekte, Übersetzung und Ausführung von "on the fly" generiertemJava-Code während der Bewertung, Begrenzung der genutzten Systemresourcen (Laufzeit,persistenter Speicherplatz, Hauptspeicher), AusführungdesstudentischenCodesunddesBewertungscodes in verschiedenen, separat abgesichertenSchutzbereichen.
Abbildung 1: Stark vereinfachte Beispielaufgabe 2.3 Bewertung mit Graja
Den Bewertungsaspekt (1) überprüft der in Abbildung 2 dar-gestellte, mit Graja kompatible Code.Der Aufruf der internen Programmschnittstelle des studentischenCodes ist in Programmzeile 06 zu finden. Davor wird eine Instanzder studentischen Klasse erzeugt und danach das beobachteteErgebnis überprüft. Diese Art von Bewertungscode ist dem in derprofessionellen Softwareentwicklung verbreiteten Testcode fürModultests sehr ähnlich. Spezialitäten der hier betrachtetenProgrammbewertung sind die in Zeile 01 vergebenen Teilpunkteund der in Zeile 08f zu findende ausführliche Fehlerhinweis.Weiterhin besonders ist die von Graja angebotenen Reflection-Bibliothek (Zeile 04f), die etwaige Exceptions in verständlicheFehlermeldungen verwandelt.Wir betrachten eine für Zwecke der konzentrierten Darstellungstark vereinfachte Programmieraufgabe (s. Abbildung 1).Diese Aufgabe verlangt vom Studierenden nicht nur dieProgrammierung einer einfachen mathematischen Formel,sondern die Implementierung einer vorgegebenen Schnittstelle.Eine korrekte Lösung kann nicht nur Hypotenusen berechnen (2);eine korrekte Lösung kann darüber hinaus Quadrate berechnen (1)und sie setzt Wiederverwendung durch Delegation ein (3). Fürjeden der im vorstehenden Satz markierten Bewertungsaspektemöchten wir Teilpunkte vergeben.2 http://junit.org/
Abbildung 2: Bewertung des Aspekts (1) Abbildung 3: Bewertung des Aspekts (2) Abbildung 4: Bewertung des Aspekts (3)Berechnen Sie die Länge der Hypotenuse eines rechtwinkligen Dreiecks. Teilen Sie den Programmcode auf zwei Klassen auf: Schreiben Sie eine weitere Klasse Hypo mit einer statischen Methode hypo, die als ersten Parameter ein Quadrat-Objekt und als zwei weitere Parameter die Längen zweier Katheten erhält. Gewünschter Rückgabewert ist die Länge der Hypotenuse. Quadrierungen soll hypo an das Quadrat-Objekt delegieren. Der Code in Abbildung 3 verwendet in Zeile 14 die Bibliothek mockito 3 zur Erzeugung eines Stubs, welches das Interface Quadrat vollständig implementiert. Die beiden folgenden Zeilen "bestücken" das Stub mit vorbereiteten Antworten auf erwartete Anfragen des SUT 4 . In Zeile 17f kommt das SUT (hier die studentische Methode hypo) zur Ausführung. Als Übergabeparameter erhält hypo das Stub-Objekt.
QuadratImplimplementiere das folgende vorgegebeneInterface:package de.hsh.prog;public interface Quadrat {double quadrat(double v); // berechnet v²}01 @Test @ScoringWeight(35.0)02 public void pruefeQuadratMethode() {03double a= 3, expected= a*a;04Quadrat studentImpl= ReflectionSupport.create(05getSubclassForName("QuadratImpl",Quadrat.class));06double observed= studentImpl.quadrat(a);07org.junit.Assert.assertEquals(08"quadrat("+a+")="+observed+" (erwartet :"+expected09+")", expected, observed, 1E-5);10 }11 @Test @ScoringWeight(25.0)12 public void pruefeGesamtfunktion() {13double a=3, b=4, cExpected=5;14 21 } 22 @Test @ScoringWeight(40.0) Quadrat stub= Mockito.5); 23 public void pruefeAufrufVonQuadrat() { 24 double a=3, b=4; 25 Quadrat mock= Mockito.mock(Quadrat.class); 26 ReflectionSupport.invokeStatic( 27 getClassForName("Hypo"),double.class,"hypo",mock,a,b); 28 try { 29 Mockito.verify(mock, Mockito.times(1)).quadrat(a); 30 Mockito.verify(mock, Mockito.times(1)).quadrat(b); 31 } catch (WantedButNotInvoked e) { 32 org.Als Bewertungssystem betrachten wir einen separaten Betriebs-systemprozess. Aus konzeptioneller Sicht lädt der Prozess drei verschiedene Komponenten und führt sie aus (vgl. Abbildung 5). Wir gehen davon aus, dass alle Komponenten aus Java Bytecode bestehen, die von derselben JVM-Instanz geladen werden: 3 http://code.google.com/p/mockito/ 4 Zur Funktionsweise der auf der ersten Blick verwirrenden Aufrufsyntax folgt eine kurze Erläuterung: Mockito.mock erzeugt ein Objekt einer zur Laufzeit mit cglib (http://cglib.sourceforge. net/) erzeugten Subklasse von Quadrat. Das wie ein normaler Methodenaufruf aussehende stub.quadrat(a) führt mockito-intern dazu, dass eine ID des aktuell ausgeführten Threads in
mock(Quadrat.class); 15 Mockito.when(stub.quadrat(a)).thenReturn(a*a); 16 Mockito.when(stub.quadrat(b)).thenReturn(b*b); 17 double c= ReflectionSupport.invokeStatic( 18 getClassForName("Hypo"),double.class,"hypo",stub,a,b); 19org.junit.Assert.assertEquals("hypo(q,"+a+","+b+")="+c+ 20 " (erwartet: "+cExpected+")", cExpected, c, 1Ejunit.Assert.fail("hypo muss die Quadrierung "+ 33 "an den Quadrat-Parameter delegieren"); 34 }2.4 Test Doubles: Stubs und MocksÄhnlich ließe sich nun der Bewertungsaspekt (2) untersuchen, indem eine QuadratImpl-Musterlösung als Parameter an die studentische hypo-Methode übergeben wird. Die erneute Verwendung einer u. U. fehlerhaften studentischen QuadratImpl-Klasse würde die Bewertung des Aspekts (2) negativ verzerren. Der Fehler würde in zwei Bewertungsaspekten "gezählt". Als Alternative zu einer eigenen Musterlösung kann man ein Test Double [Me07] einsetzenein Platzhalter-Objekt, mit dem ein untersuchter Programmteil (das sog. system under test -kurz SUT) während des Tests interagiert. Stub-Objekte sind Test Doubles, die vorgefertigte Antworten an das SUT liefern. Der Bewertungsaspekt (3) lässt sich schließlich durch eine weitere Test Double Variante, die sog. Mock-Objekte realisieren (vgl. Abbildung 4). Ein Mock-Objekt wird in Zeile 25 erstellt, welches die Quadrat-Schnittstelle implementiert. Da uns bei diesem Bewertungsaspekt das Berechnungsergebnis nicht interessiert, programmieren wir keine vorbereiteten Antworten. Stattdessen befragen wir das Mock-Objekt nach Ausführung des SUT in Zeile 29f, ob es Aufrufe mit den angegebenen Parametern erhalten hat.3. Sicherheit des BewertungssystemsDer Ansatz, studentische Lösungen dynamisch zu analysieren, erfordert die Ausführung des studentischen Codes. Im Unterschied zu herkömmlichen Software-Tests, wo Tester und Autor einander vertrauen (bei Unit-Tests oft sogar dieselbe Person sind), wo also die Testumgebung vom zu testenden System kein böswilliges Verhalten zu befürchten hat, ist dies beim Test von studentischen Einreichungen anders. Hier muss mit Angriffen des getesteten Codes auf die Testumgebung gerechnet werden. Einige Angriffsbeispiele stellt Abschnitt 3.4 vor. Dazu kommen unabsichtliche Programmierfehler in weitaus größerem Umfang als bei Tests professioneller Software. Schutzmaßnahmen gegen solche Angriffe sind daher unabdingbar. In diesem Abschnitt wollen wir konkrete Bedrohungen und Gegenmaßnahmen beleuchten. 3.1 Schutzbereiche einer Datenstruktur zusammen mit dem stub-Objekt und dem Wert a abgelegt wird. Der Rückgabewert von stub.quadrat(a) wird zwar an Mockito.when weiter gereicht, dort jedoch nicht ausgewertet. Stattdessen weist die ID des aktuell ausführenden Threads den Weg zum soeben abgelegten stub-Objekt.
Tabelle 1: Betrachtete Merkmale der Komponenten-Autoren Nr. Merkmal Ausprägungs- grad 7 für …
Komponente, die in der Regel von Lehrkräften oder Hilfspersonalerstellt wird, ist weniger kritisch, den AutograderCode erachtenwir als Komponente mit dem geringsten Bedrohungspotential.Um das Bedrohungspotential 6 der einzelnen Komponenteneinschätzen zu können, betrachten wir zunächst die in Tabelle 1aufgeführten Merkmale der Komponenten-Autoren. Die beidenersten Merkmale begünstigen bei hoher Ausprägung unabsichtlichherbeigeführte Bedrohungen, das dritte Merkmal begünstigtabsichtlich herbeigeführte Bedrohungen, das vierte Merkmalbegünstigt jede Art von Bedrohung.Autograder-Core Assignment-GraderSubmission1Geringe Programmiererfahrung--+2Geringe Bereitschaft, Zeit für die korrekte Pro-grammierung der Komponente aufzuwenden-0 +3"Kriminelle Energie", d. h. Bereitschaft, Bedrohungen absichtlich herbei zu führen.--+4Größe der Autorengruppe-0 +Vor diesem Hintergrund erwarten wir von der Submission-Kom-ponente das größte Bedrohungspotential. Die AssignmentGrader-
Wenn wir davon ausgehen, dass Submission-Code in wenigstens einem Verzeichnis Schreibrechte eingeräumt werden müssen, ist dieser denial of service Angriff mit Mitteln der Java Sicherheitsarchitektur unseres Wissens nicht abwehrbar. Hier müssen dem die JVM beherbergenden Betriebssystemprozess Ressourcen in begrenztem Maße zugeteilt werden. Beispielsweise in Form einer separaten Festplattenpartition oder in Form einer Datei begrenzter Größe, die als loopback device verwendet wird. Ähnlich müssen die Ressourcen Hauptspeicher und CPU-Zeit durch die Umgebung der JVM begrenzt werden, etwa über einen Parameter zum maximalen Speicherverbrauch beim JVM-Start bzw. mit Hilfe des Linuxkommandos timeout.
Abbildung 6: Aufrufstapel und resultierende Rechte (Beispiel) Abbildung 7: Privilegierter Callback eines Test Doubles DamitProgrammcode eines eingeschränkten Anwendungsbereichs darf durch Aufruf einer Operation des Systembereichs selbstverständlich keine zusätzlichen Rechte erlangen. Die JVM ermittelt daher die Schnittmenge der Rechte aller am Aufrufstapel beteiligten Schutzbereiche, um eine potentiell bedrohliche Operation zu überprüfen [Go13]. Die Aufrufreihenfolge zur Laufzeit ist in der Regel Code des Systembereichs Rechte (bspw. Einlesen von Font-Dateien zwecks Erzeugung einer Ausgabe) erhalten kann, die aufrufender Anwendungsbereichs-Code nicht besitzt, gibt es 11 Rückwärts gewandte Aufrufe von Methoden des Autograder-Core aus dem AssignmentGrader heraus sind ebenfalls denkbar, sind jedoch hier nicht Gegenstand der Betrachtung. in Java den doPrivileged-Aufruf. Ein solcher Aufruf wirkt als Abbruchskriterium bei der Bildung der o. g. Rechte-Schnittmenge. Oberhalb des doPrivileged-Aufrufs am Aufrufstapel beteiligte Schutzbereiche werden nicht berücksichtigt. Wäre etwa im Beispiel der Abbildung 6 der Aufruf der Methode d ein privilegierter Aufruf, würde die resultierende Schnittmenge die Rechte {2, 4} umfassen. Beim Einsatz von Test Doubles ruft Submission-Code Test Doubles des AssignmentGrader-Schutzbereichs auf (vgl. Aufruf der Methode h in Abbildung 7). Ohne besondere Vorkehrungen würde der Code im Test Double mit den Rechten der Schnittmenge (AutograderCore ∩ AssignmentGrader ∩ Submission) ausgeführt, also der Rechtemenge {4}. Der von mockito erzeugte Bytecode eines Test Doubles ruft jedoch Methoden der mockito Bibliothek auf (Methode i), die weitgehende Rechte erfordern, u. a. das sehr potente Recht java.lang.reflect.ReflectPermission "suppressAccessChecks", welches den Zugriff auf private und protected member einer Klasse erlaubt (in Abbildung 7 in der Spalte "Recht 5" vorstellbar). Eine Lösung kann nun nicht sein, dem Submission-Schutzbereich alle Rechte zu gewähren, die das Test Double benötigt. Mindestens das Beispiel in Abschnitt 3.4.2.5 spricht dagegen. Wäre der Aufruf der Methode h privilegiert, würden die Methoden h und i mit der Rechtemenge {2, 4, 5} ausgeführt. Leider hat der Autor des AssignmentGraders keine Möglichkeit, den Test Double-Aufruf privilegiert zu gestalten. Die Programmierschnittstelle von mockito, wie wir sie in Abschnitt 2.4 kennen gelernt haben, ermöglicht keine privilegierten Test Doubles. Der eigentliche Methodenaufruf findet im Submission-Code statt, der nicht im Einflussbereich des AssignmentGrader-Autors steht.
4.2 Sicherheitsimplikationen durch TestDoubles
11 AutograderCore → AssignmentGrader → Submission (vgl. Abbildung 6). Mit zunehmender Aufruftiefe stehen geringere Rechte zur Verfügung.
Abbildung 8: Proxy-Klasse für ein Test Double von Quadrat Dievorgeschlagene Lösung besteht nun darin, eine Proxy 12 -Klasse in der AssignmentGrader-Komponente zu erstellen, die ein Test Double umhüllt. Beispielhaft ist in Abbildung 8 das Quadrat-Interface und das zugehörige, mit Mockito.mock erzeugte Test Double 13 zu sehen.
Die Proxy-Klasse besitzt genau die gleiche Schnittstelle wie das Original (Quadrat) und eine dauerhafte Referenz zum Test Double Objekt. Die Implementierung der quadrat-Methode der Proxy-Klasse besteht nun aus einem privilegierten Aufruf von TestDouble<Quadrat>.quadrat. 12 http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Pro xy.html 13 Der von mockito erzeugten Klasse haben wir hier für Darstellungszwecke einen Namen gegeben. In Wirklichkeit ist die erstellte Klasse aus Benutzersicht anonym.
Die zentrale Operation (vgl. Abschnitt 2.4) bei der Nutzung von mockito ist die generische Methode Mockito.mock(Class<T> c) 14 . Sie liefert ein Test Double vom Basistyp T, für das alle Methoden der Klasse T aufrufbar sind. Das Test Double wird im weiteren Verlauf von Methoden wie Mockito.when oder Mockito.verify verwendet. An dieser Art des Aufrufs von mockito soll sich durch die beschriebene Sicherheitsanforderung nichts ändern. Einzig der Name der Einstiegsklasse Mockito soll nun MockitoWrap heißen. Die vollständige Beschreibung von MockitoWrap würde den Rahmen dieses Aufsatzes sprengen. Wir nennen nur einige grundlegende Entwurfsideen, die vermutlich in ähnlicher Form auf andere Mock-Frameworks übertragen werden können. MockitoWrap wird im Zuge der Erstellung neuer Programmieraufgaben sukzessive an der Hochschule Hannover weiter entwickelt. Entwurfsidee 1: Sei Class<T> c der Typ, für den ein Test Double erstellt werden soll. Statt direkt Mockito.mock(c) aufzurufen, soll der Wrapper genutzt werden: MockitoWrap.mock(c). Der Wrapper delegiert den Aufruf an das Original (T td=Mockito.mock(c)) und erstellt dann ein Proxy-Objekt für das Test Double td. Das Proxy-Objekt erhält als Konstruktorparameter ein Objekt einer neuen generischen Klasse MockProxyInvocationHandler<T>, die von InvocationHandler 15 erbt. MockProxyInvocationHandler<T> besitzt als Instanzattribute Referenzen auf das Test Double td und dessen Klasse c 16 , so dass stets vom Proxy-Objekt zum Test Double navigiert werden kann. Entwurfsidee 2: Die Methode MockProxyInvocationHandler<T>. invoke delegiert den Methodenaufruf innerhalb einer Privileged Action 17 an das Test Double td.
Über diese nicht abschließende Aufzählung hinaus sind selbstverständlich viele weitere Schnittstellen denkbar (Umgebungsvariable, Audio/Video, Netzwerk, etc.).In der Praxis entspricht jede Komponente einem jar-Archiv oder jeweils einer Menge von jar-Archiven. Jedem jar-Archiv wird ein Satz von Rechten zugeordnet.Wir meinen hiermit das, was in etablierten Risikoschätzmethoden wie[oV13] "likelihood" genannt wird.7 Legende: -=gering, 0=mittel, +=hochWeitere s. z. B. http://docs.oracle.com/javase/7/docs/technotes/ guides/security/permissions.htmlNoch dazu muss immer wieder mit neu entdeckten Sicherheitslücken in der Java Sandbox gerechnet werden.http://docs.mockito.googlecode.com/hg/latest/index.html?org/ mockito/Mockito.htmlhttp://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Invo cationHandler.htmlType erasure bei Java Generics macht den Einsatz dieses zweitgenannten Instanzattributs notwendig.http://docs.oracle.com/javase/7/docs/api/java/security/Privi legedAction.html
Test Doubles bei aktivem Securitymanager
Das vorangegangene Kapitel hat motiviert, dass der Einsatz der Java Securitymanagers sinnvoll ist, um reale Bedrohungen abzuwenden. Die durch den Einsatz des Securitymanagers resultierenden Auswirkungen auf den Einsatz von Test Doubles sind Gegenstand des nun folgenden Kapitels.
LiteraturverzeichnisUsing Test-Driven Development in the Classroom: Providing Students with Automatic, Concrete Feedback on PerformanceSEdwardsProc. Int'l Conf. Education and Information Systems: Technologies and Applications (EISTA '03)Int'l Conf. Education and Information Systems: Technologies and Applications (EISTA '03)Aug. 2003Java TM SE Platform Security ArchitectureLGongPractical Unit Testing with JUnit and MockitoTKaczanowski2013Verlag Tomasz KaczanowskiWeb-basierte Programmierpraktika mit PraktomatJKrinkeMStörzerAZellerSoftwaretechnik-Trends223October 2002xUnit Test Patterns: Refactoring Test CodeGMeszaros2007Addison-Wesley LongmanAmsterdam.VOWASP Risk Rating Methodology09.2013Enabling Graph Transformations on Program CodeMStrieweMBalzMGoedickeProceedings of the Fourth International Workshop on Graph-Based Tools (GraBaTs 2010)the Fourth International Workshop on Graph-Based Tools (GraBaTs 2010)Enschede, Netherlands2010ASpillnerTLinzBasiswissen Softwaretest (3. Auflage)Heidelberg, Germanydpunkt2005Evaluation automatisierter Programmbewertung bei der Vermittlung der Sprachen Java und SQL mit den Gradern "aSQLg" und "Graja" aus studentischer PerspektiveAStöckerSBeckerRGarmannFHeineCKleinerOJBottProceedings DeLFIDeLFI2013Supporting student-written tests of GUI programsMThorntonSHEdwardsRPTanMAPérez-QuiñonesProceedings of the 39 th SIGCSE Technical Symposium on Computer Science Educationthe 39 th SIGCSE Technical Symposium on Computer Science EducationNew York, NYACM Press2008