Programmierung: Scripting Engine

[BorisM]

Nachdem hier ja doch einige aktive Programmierer unterwegs sind, wollte ich mal fragen, ob jemand Erfahrung mit Scripting Engines hat.

Folgende Problemstellung: Für StellSi nutze ich momentan das mit QT mitgelieferte QtScript, das ECMA implementiert. Inzwischen hat sich gezeigt, dass QtScript für diesen Zweck hoffnungslos unterdimensioniert ist (man könnte es auch als rechten Klump bezeichnen :-) ), deswegen bin ich momentan auf der Suche nach einer Alternative.

Gefunden habe ich dabei AngelScript, das meine Anforderungen sehr gut erfüllt. Allerdings bin ich mir hier etwas unsicher bezüglich der Sicherheit. Ich habe keine Hinweise darauf gefunden, dass AngelScript hier problematisch ist, und es wird auch aktiv weiterentwickelt, allerdings muss das ja nichts heißen. In den diversen Spielprogrammierforen, wo natürlich über Scripting diskutiert wird, kommt das Thema Sicherheit leider sehr kurz.

Daher wollte ich mal fragen, ob sich hier schon mal jemand mit dem Thema auseinandergesetzt hat, vielleicht eine Meinung zu AngelScript hat - oder eine gute Alternative kennt. Wichtig für mich ist dabei, dass das System Klassen und das Ableiten von Klassen (sei es jetzt in Form von Vererbung, sei es in Form von "automatischem C&P") unterstützt, und eine ganz brauchbare Performance bietet.

[Andreas Karg]

Ein Bekannter von mir schwört auf Lua, das eine Lua/C-API besitzt, mit der man nativ kompilierte C-Funktionen einbinden und aufrufen kann. Außerdem gibt es einen JIT-Compiler für die Sprache, der gar nicht schlecht ist. Selber hab ich damit bisher allerdings noch fast nix gemacht.

[BorisM]

Mit Lua kann ich mich nicht so wirklich anfreunden - ich finde die Syntax ziemlich...seltsam. Das ist halt das was mir an AngelScript gefällt - es ist schon deutlich an C++ angelehnt, und es unterstützt Vererbung auf relativ mächtigem Ansatz. Auch ist die Einbindung in ein umgebendes Programm recht gut gelöst in meinen Augen.

Mein Problem ist halt nur - AngelScript ist sicherlich deutlich weniger gängig als sowas wie Lua, und da frage ich mich halt, ob man dem System vertrauen kann.... Eine ScriptingEngine kann halt, wenn sie fehlerhaft ist, auch ziemlich viel Schaden anrichten...

[Andreas Karg]

Was für sicherheitsrelevantes Zeugs hast du denn damit vor? Möchtest du mit Stellsi echte Stellwerke fernsteuern?

[BorisM]

Was für sicherheitsrelevantes Zeugs hast du denn damit vor? Möchtest du mit Stellsi echte Stellwerke fernsteuern?

Nein. Trotzdem - wenn man Software ausliefert, sollte man schon sehr genau drauf achten, dass diese nicht missbraucht werden kann. Das Konzept von StellSi sieht vor, dass Add-Ons eben auch Skripte enthalten können. Deswegen sollte nach Möglichkeit ausgeschlossen werden, dass diese Skripte missbräuchliche Funktionen ausführen können. Insbesondere sollen die Skripte keinen Zugriff auf die Festplatte oder den Speicher bekommen. Ein solcher Zugriff ist in AngelScript natürlich nicht vorgesehen, die Frage ist halt, ob man sich darauf verlassen kann.

Um das Problem zu lösen, muss zum einen ich als Programmierer sorgfältig arbeiten. Aber - die Sicherheit der ScriptEngine selber kann ich nicht nachprüfen, da muss ich mich darauf verlassen, die die Programmierer der Engine gute Arbeit geliefert haben, und muss entsprechend natürlich auch im Auge behalten, ob Sicherheitslücken bekannt werden. Von daher stellt sich in meinen Augen die Frage nach der Sicherheit eines solchen Systems durchaus.

Natürlich kann man das Problem lösen, indem man nur signierte Skripte zulässt - aber so ganz zielführend kommt mir das nicht vor.

[Andreas Karg]

Ah, jetzt komme ich so langsam dahinter, worauf du rauswillst. Mein Brötchengeber arbeitet momentan hart daran, sein Produkt mit einem CE-Stempel zu versehen (erste Experimente mit geschnitzten Kartoffeln waren vielversprechend), deswegen bin ich mit dem Kopf grad eher in der Denkschiene "Schutz vor unbeabsichtigtem Anlaufen" drin.

Ich fürchte, ich kann dir bei deinen Problemen nicht weiterhelfen. :-(

[whoami]

Ist es möglich/denkbar, die (fremden) Skripte in einem anderen Benutzerkontext ausführen zu lassen? (z.B. durch einen Hintergrunddienst.) Das würde unabhängig von der eigentlichen Lösungsauswahl noch eine Schutzebene einziehen, die aber wenig hilft gegen ein unsicher konfiguriertes OS (Dateiberechtigungen) und OS-Sicherheitslücken.

Selbst Sandboxen haben ihre Sicherheitslücken. Je weiter solche verbreitet sind, desto besser sind sie (tendenziell) getestet, aber eben auch interessanter für das Ausforschen und Ausnutzen.

[BorisM]

Ist es möglich/denkbar, die (fremden) Skripte in einem anderen Benutzerkontext ausführen zu lassen? (z.B. durch einen Hintergrunddienst.)

Hm...müsste ich mich mal einlesen was es da für Möglichkeiten gibt - aber das klingt relativ umständlich jetzt so auf den ersten Blick. Am liebsten wärs mir ja wenn ich meinem eigenen Programm alle Rechte rauben könnte, die es nicht braucht, aber ich fürchte eine solche Möglichkeit bietet Windows nicht an.

Wahrscheinlich habe ich auch einfach Paranoia, aber ich denke lieber zu viele Gedanken gemacht als zu wenig.

Nachdem ein Bekannter von mir jetzt meinte, dass er einige Spiele auf der Referenzliste von AngelScript kennt (ich kenn mich im Spielesegment halt überhaupt nicht aus), hat sich mein Vertrauen jedenfalls etwas erhöht, so dass ich mich jetzt entschieden habe es zu verwenden - die Vorteile, die es bietet, sind halt einfach sehr groß. Generell wirkt die Bibliothek auch sehr durchdacht - bis auf das allgemeine Unwohlsein habe ich eigentlich nichts gefunden was dagegen sprechen würde.

[Dennis Bork]

Natürlich kann man das Problem lösen, indem man nur signierte Skripte zulässt - aber so ganz zielführend kommt mir das nicht vor.

...oder vielleicht indem man eine "sichere" Downloadquelle bereitstellt? Mit einer .zad-Datei kann man ja auch eine Menge böswilliges anstellen ... wenn das ZPA bzw. Carsten diese zum Download bereitstellen sind sie "offiziell" und somit vertrauenswürdig. Wenn Du also eine Möglichkeit hast externe Skripte für den StellSi auf ihre Sicherheit zu prüfen und dann zum Download bereitzustellen könnte das den Anforderungen doch eventuell genüge tun.

[BorisM]

...oder vielleicht indem man eine "sichere" Downloadquelle bereitstellt? Mit einer .zad-Datei kann man ja auch eine Menge böswilliges anstellen ... wenn das ZPA bzw. Carsten diese zum Download bereitstellen sind sie "offiziell" und somit vertrauenswürdig. Wenn Du also eine Möglichkeit hast externe Skripte für den StellSi auf ihre Sicherheit zu prüfen und dann zum Download bereitzustellen könnte das den Anforderungen doch eventuell genüge tun.

Die "offiziellen" Skripte sind denke ich das kleinste Problem. Aber es gibt ja auch bei Zusi "inoffizielle" Add-Ons, die von vielen installiert werden, und eben nicht durchs ZPA gegangen sind.

[Andreas Karg]

Kannst du da nicht einfach einen Haftungsausschluss reinpacken?

[Mr. X]

Aber es gibt ja auch bei Zusi "inoffizielle" Add-Ons, die von vielen installiert werden, und eben nicht durchs ZPA gegangen sind.

Dann ist das ja wohl die Verantwortung dessen, der die installiert, und nicht desjenigen, der die Werkzeuge bereitstellt, sie zu installieren. Dem Nutzer die Möglichkeit zu nehmen, inoffizielle, also nicht-signierte Scripts auszuführen, etc., ist einfach nur unnütze Gängelung der Nutzer. Es gibt keinen vernünftigen Grund, inoffiziellen Sachen per se das Prädikat "böse" zu geben und auch offizielle Sachen können kompromittiert sein.
Eine funktionale Einschränkung, d.h. gefährliche Aktionen zu unterbinden, kann hingegen durchaus sinnvoll sein. Ein Nutzer braucht im StellSi sicherlich kein Script, dass einen Datenträger formatiert.

[BorisM]

Aber es gibt ja auch bei Zusi "inoffizielle" Add-Ons, die von vielen installiert werden, und eben nicht durchs ZPA gegangen sind.

Dann ist das ja wohl die Verantwortung dessen, der die installiert, und nicht desjenigen, der die Werkzeuge bereitstellt, sie zu installieren. Dem Nutzer die Möglichkeit zu nehmen, inoffizielle, also nicht-signierte Scripts auszuführen, etc., ist einfach nur unnütze Gängelung der Nutzer. Es gibt keinen vernünftigen Grund, inoffiziellen Sachen per se das Prädikat "böse" zu geben und auch offizielle Sachen können kompromittiert sein.
Eine funktionale Einschränkung, d.h. gefährliche Aktionen zu unterbinden, kann hingegen durchaus sinnvoll sein. Ein Nutzer braucht im StellSi sicherlich kein Script, dass einen Datenträger formatiert.

Um Gottes Willen, eine Einschränkung einbauen will ich auf keinen Fall - ich wollte damit nur verdeutlichen, dass diese Variante keine absolute Sicherheit bringt.

Funktional eingeschränkt ist das ganze sowieso - AngelScript bietet im Grundzustand gar keine Möglichkeiten, mit der Außenwelt zu kommunizieren, noch nicht mal eine Funktion um Daten auf der Kommandozeile auszugeben existiert. Die Kommunikationsmöglichkeiten kommen erst dadurch zustande, dass man bestimmte C++-Funktionen in AngelScript einbindet. Die offizielle Schnittstelle ist also klar definiert. Das Grundkonzept ist also sicher.

Meine Sorge bezieht sich eigentlich nur auf mögliche Fehler in der Skripting Engine, die es ermöglichen könnten, die offiziellen Wege zu umgehen.

Die Skripte bekommen zwar keinen direkten Zugriff auf das Netzwerk, aber da StellSi Netzwerkspiele ermöglichen soll, müssen natürlich auch Daten, die per Skript erzeugt wurden, nach außen transportiert werden. Natürlich muss ich dann kontrollieren, was für Daten das Skript mir liefert, bevor ich sie über das Netzwerk schicke, aber trotzdem wäre das Skript hier in der Lage, auf diesem Weg Daten (zumindest geringere Mengen) nach außen zu schmuggeln. In Zusammenhang mit einem hypothetischen Fehler in AngelScript, der Zugriff auf die Festplatte ermöglicht, wäre das also eine potentielle Sicherheitslücke.
Allerdings - wenn ich mir grade anschau was ich mir da zusammengestrickt habe, frage ich mich schon ob dieses Angriffsszenario relevant ist.

Zum Thema Haftungsausschluß: Natürlich kann und werde ich so etwas reinpacken, aber das entbindet mich IMHO nicht davor, mir über solche Themen Gedanken zu machen.

[Dennis Bork]

Zum Thema Haftungsausschluß: Natürlich kann und werde ich so etwas reinpacken, aber das entbindet mich IMHO nicht davor, mir über solche Themen Gedanken zu machen.

Sehr löblich. Wenn man sich dagegen den Grundtenor der Softwareindustrie so anschaut...