Sicherheit der Scala Laufzeit

Question

Ich bin Entwickler von Robocode Motor. Wir möchten Robocode mehrsprachig machen und Scala scheint gut zu sein. Wir haben Scala-Plugin prototype here.

Das Problem: Da Benutzer kreative Programmierer sind, können sie versuchen, Kampf verschiedene Möglichkeiten, um zu gewinnen. Außerdem werden Roboter aus der Online-Datenbank heruntergeladen, wo jeder eine hochladen kann. So Lücke in Sicherheit kann zu Sicherheit Loch in Benutzer Computer führen. In Java geschriebene Roboter laufen in eingeschränkter Sandbox. Fast alles ist verboten [Netzwerk, GUI, Disk (begrenzt), Threads (begrenzt), Klassenlader und Reflexion]. Die Sandbox ähnelt dem Browser-Applet. Wir verwenden Security, benutzerdefinierte Classloader per Roboter, etc ...

Es gibt zwei Möglichkeiten, wie Scala Laufzeit in Robocode Gastgeber:

1) laden sie zusammen mit Roboter in der Sandbox. Ziemlich sicher für uns, bevorzugte Lösung. Aber es wird Scala Laufzeitfähigkeiten beschädigen, weil Laufzeit Reflexion verwendet. Vielleicht generiert Klassen zur Laufzeit? Verwenden Sie Threads, um eine interne Bereinigung durchzuführen? Zugang zu JVM/Interna? (Ich möchte die Fähigkeiten der Sprache nicht einschränken)

2) benutze Scala Laufzeit als vertrauenswürdiger Code, außerhalb der Box, Sicherheit auf gleiche Ebene wie JDK. Sichtbarkeit für (bösartigen) Roboter. Sind die Scala Runtime APIs sicher? Haben Methoden sie Sicherheit Wachen? Gibt es einen abgesicherten Modus? Gibt es Singleton in Scala Laufzeit, , die missbraucht werden könnte, um zwischen Robotern zu kommunizieren? Irgendeine Konsistenz/Threadpool/Messaging, die Threads simulieren könnte? (Gibt es ein Sicherheits-Audit für Scala-Laufzeit?)

3) Etwas dazwischen, einige Klassen von Laufzeit in und einige aus. Welche Klassen/Pakete müssen für den Roboter sichtbar sein/welche sind nur private Implementierungen? (Dies scheint zukünftige Lösung zu sein)

Die Frage: Ist es möglich, aufzuzählen und zu isolieren, die Teile der Laufzeit, die in vertrauenswürdigen Umfang vom Rest laufen müssen? Spezifische Pakete und Klassen? Oder bessere Idee?

Ich bin auf der Suche nach einer bestimmten Antwort, die zu einer sicheren Lösung führt. Zufällige Gedanken willkommen, aber nicht vergeben. Es gibt eine laufende Diskussion unter scala email group. Noch keine konkrete Antwort.

Answer 1

Ich denke # 1 ist deine beste Wette und sogar das ist ein bewegliches Ziel. Wie auf der Mailingliste erwähnt, verwenden Strukturtypen Reflexion. Ich glaube nicht, dass Strukturtypen in der Standardbibliothek üblich sind, aber ich glaube nicht, dass irgendjemand merkt, wo sie sind.

Es gibt auch immer die Möglichkeit, dass es hinter den Kulissen andere Funktionen gibt, die die Reflexion verwenden. Zum Beispiel benutzte eine Array-Funktionalität für eine Weile im 2.8-Zweig die Reflexion. Ich denke, das wurde nach dem Benchmarking geändert, aber es gibt immer die Möglichkeit, dass es ein Problem gibt, bei dem jemand sagte: "Aha! Ich werde Reflektion verwenden, um das zu lösen."

Die Scala-Standardbibliothek ist mit Singletons gefüllt.Die meisten von ihnen sind unveränderlich, aber ich weiß, dass das Scheduler-Objekt in der Aktor-Bibliothek für die Kommunikation missbraucht werden könnte, weil es im Grunde ein Proxy für einen tatsächlichen Scheduler ist, so dass Sie Ihren eigenen benutzerdefinierten Scheduler hineinstecken können.

Zu dieser Zeit glaube ich nicht, dass Scala einen benutzerdefinierten Klassenlader benötigt und alle seine Klassen werden zur Kompilierzeit statt zur Laufzeit produziert, aber dann ist das wahrscheinlich ein bewegliches Ziel. Scala erzeugt viele Klassendateien, und es wird immer davon geredet, dass einige von ihnen zur Laufzeit erzeugt werden, wenn sie benötigt werden, anstatt zur Kompilierzeit.

Also, kurz gesagt, ich glaube nicht, dass es möglich ist (innerhalb vernünftiger Aufwandsbeschränkungen), die Teile von Scala aufzuzählen und zu isolieren, die vertrauenswürdig sind (und sollten).

Answer 2

Da Sie andere J * Sprachimplementierungen erwähnt haben, die alle von Reflexionen Gebrauch machen können, wäre es ein Verbot für alle diese Sprachen, solange die Reflexion nicht Teil des Spiels ist. Ich denke, das wäre das Problem von JVM, den Bereich der Reflektions-API nicht zu partitionieren, so dass man den Teil des Codes, der sich darin widerspiegeln könnte, "sandboxieren" könnte.