arbeiten:safely_and_flexibly_sandboxing_python_code_in_a_c_runtime

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste ÜberarbeitungBeide Seiten der Revision
arbeiten:safely_and_flexibly_sandboxing_python_code_in_a_c_runtime [07.10.2019 12:28] – Erstellt mit dem Formular arbeiten:anlegen Juergen Hahnarbeiten:safely_and_flexibly_sandboxing_python_code_in_a_c_runtime [07.10.2019 12:38] – Juergen Hahn
Zeile 20: Zeile 20:
  
 === Hintergrund === === Hintergrund ===
- 
 Das Sandboxing von Applikationen ist eine Methode in der Software Emtwicklung, um die Kontexte, in denen Code ausgeführt werden kann, einzuschränken. Das Sandboxing von Applikationen ist eine Methode in der Software Emtwicklung, um die Kontexte, in denen Code ausgeführt werden kann, einzuschränken.
 Dementsprechend wird die Sicherheit einer Applikation vor externen Angreifern, Schadsoftware aber auch gegenüber unerwüschten Zugriffen auf Systemresourcen oder von anderen Applikationen gesteigert. Dementsprechend wird die Sicherheit einer Applikation vor externen Angreifern, Schadsoftware aber auch gegenüber unerwüschten Zugriffen auf Systemresourcen oder von anderen Applikationen gesteigert.
Zeile 27: Zeile 26:
 Ein Beispiel aus dem Videospielkontext ist die Implementierung eines Projektils. Ein Beispiel aus dem Videospielkontext ist die Implementierung eines Projektils.
 Der Anwendungsentwickler "scriptet" ein Projektil und definiert das Aussehen, die Größe, die Geschwindigkeit, den Schaden bei einem Treffer (das "Was"), usw., während die Engine die rechenaufwendigen Aspekte übernimmt, wie die Physiksimulation (z.B. Schwerkraft), Kollisionserkennung (Hit-Boxes), etc. (das "Wie"). Der Anwendungsentwickler "scriptet" ein Projektil und definiert das Aussehen, die Größe, die Geschwindigkeit, den Schaden bei einem Treffer (das "Was"), usw., während die Engine die rechenaufwendigen Aspekte übernimmt, wie die Physiksimulation (z.B. Schwerkraft), Kollisionserkennung (Hit-Boxes), etc. (das "Wie").
-Skriptsprachen werden für solche Anwendungsszenarien bevorzugt eingesetzt, da sie schnelle Iteration erlauben, leichter zu verwenden sind als C/C++ und auch Entwicklungen dritter zulassen (Modding+Skriptsprachen werden für solche Anwendungsszenarien bevorzugt eingesetzt, da sie schnelle Iteration erlauben, leichter zu verwenden sind als C/C++ und auch Entwicklungen Dritter zulassen (Modding).
  
 === Zielsetzung der Arbeit === === Zielsetzung der Arbeit ===
  
-In dieser Arbeit soll anhand des Threat-Modelling-Prinzips für eine gegebene C++-Runtime, die Scripting mit Pyhton 3 unterstützt, erarbeitet werden, innerhalb welcher Szenarien es für Benutzer möglich ist sich aus der Runtime "rauszuhacken". +In dieser Arbeit soll erarbeitet werden, innerhalb welcher Szenarien es für Benutzer möglich ist sich aus einer C++-Runtime mit Python3-Scripting "herauszuhacken". 
-Hierbei geht es primär um unbeabsichtigte "Attacken", wie Bugs und undefiniertes Verhalten in den Scripts abzufangen, als konkret sich gegen böswillige Angriffe zu verteidigen. +Dabei soll Threat-Modeling angewandt werden. 
-Im nächsten Schritt soll ausgehend vom State of the Art von Sandboxing anhand der evaluaierten Szenarios eine Integration der Sandbox für Python 3 Scripting in die C++-Runtime vorgenommen werden.+Hierbei geht es primär um unbeabsichtigte "Attacken", wie Bugs und undefiniertes Verhalten in den Scripts abzufangen, als sich konkret gegen böswillige Angriffe abzusichern. 
 +Anhand der evaluierten Szenarien soll im nächsten Schritt, ausgehend vom State of the Art des Sandboxing, eine Integration der Sandbox für Python3-Scripting in die C++-Runtime vorgenommen werden.
 In einem weiteren Schritt soll evaluaiert werden, ob das Sandboxing hinreichend gegen das Threat-Model schützt. In einem weiteren Schritt soll evaluaiert werden, ob das Sandboxing hinreichend gegen das Threat-Model schützt.
  
Zeile 40: Zeile 40:
 * Aufbereitung von Literatur zum Thema (1 Woche) * Aufbereitung von Literatur zum Thema (1 Woche)
 * Erstellen des Threat-Models (1 Wochen) * Erstellen des Threat-Models (1 Wochen)
-* Integration des Thread Models in C++-Runtime (2 Wochen) +* Integration des Threat Models in C++-Runtime (2 Wochen) 
-* Testing des Thread Models und Bugfixing (1 Woche) +* Testing des Threat Models und Bugfixing (1 Woche) 
-* Evaluation der Sanbox (1 Woche)+* Evaluation der Sandbox (1 Woche)
 * Schriftliche Ausarbeitung (2 Wochen) * Schriftliche Ausarbeitung (2 Wochen)