Das deutsche Python-Forum

Hallo,

Ich weiß noch gar nicht, ob ich hier mit meiner Frage überhaupt richtig bin. Falls nicht, entschuldige ich mich schonmal im Voraus.

Ich möchte IronPython gern als Script-Erweiterung für meine .NET Programme anbieten. Habe auch schon ein wenig damit experimentiert und es funktioniert soweit alles.

Eine Sache macht mir aber gerade Sorgen:
Wenn ich der Scriptengine den Zugriff auf ein oder mehrere Controls erlaube (z.B. scope.SetVariable("MyTextBox", MyTextBox)), dann kann ich mich via IronPython locker "hochhangeln".
z.B. Und einmal "oben" angekommen, kann ich allen möglichen Unsinn treiben.
Ich hab's noch nicht ausprobiert, aber eventuell käme ich sogar an die Datenbank-Klasse ran. Und da hört der Spass dann auf.

Jetzt suche ich nach einem Weg, wie ich den Scope effektiv eingrenzen und unter meiner Kontrolle halten kann.
Die Scope-Klasse selber bietet mir ja nur die Möglichkeit, Variablen und Objekte an die Engine zu übergeben, aber nichts womit ich Objekte auch sperren oder exkludieren könnte.

Oder doch?

Wäre schön, wenn jemand eine Idee hätte.

Danke schonmal!

Lucky

Wenn .NET da keine eigenen Moeglichkeiten bietet, dann wird das nix. Alternativ koenntest du die Berechnungen in einen eigenen Prozess ausgliedern, welcher auf die erlaubten Objekte via Remote-Proxies zugreift. Ist uU nicht besonders performant (relativ, ist ja alles lokal).

Bleibt die Frage zu klaeren: warum der Aufriss? Ein GUI-Programm auf einer Maschine des Benutzers - da kann der doch eh so ziemlich alles machen, inklusive DB-Verbindungen oeffnen oder abgreifen dank wireshark & co.

Naja, stell dir vor, die Software wird in einem Büro von einer Handvoll Leute eingesetzt. Und jetzt kommt der Praktikant und spielt den Damen Streiche, wie dass z.B. Buttons "verschwinden" etc. Und wer wird dann ganz hysterisch angerufen? Ich.

Das Scripting sollte eigentlich nur das Customizing etwas erleichtern. Und da möchte man sich schon halbwegs drauf verlassen können, dass der Scope begrenzt bleibt.
Eine 100%ige Sicherheit gibt es freilich nirgendwo. Aber man muss sich halt entscheiden, welche Sicherheit man bereitstellen will und welche Risiken man eher in Kauf nimmt, weil der Aufwand zu groß wäre.

Obiges Szenario wär mir schon "zu viel".

Ich halte das fuer ueberkanditelt. Wenn du tatsaechlich Probleme hast, dann geh damit um. Und ein Praktikant, der clever genug ist, sich durch solche Tricks erweiterte Zugriffe zu verschaffen, der baut im Zweifelsfall was nuetzlicheres, als du denkst.

Aber wie dem auch sei: Python selbst kann's nicht, Jython kann's nicht, PyPy koennte es, hilft dir aber nix, und IronPython kann es AFAIK auch nicht. Wenn es also nicht irgendwelche .NET-eigenen Sandboxing-Kram gibt (den ich auf diesem Niveau auch fuer unwahrscheinlich halte - entweder kann man GUI, oder man kann nicht, einen Objektbaum partiell zu beschraenken ist doch sehr speziell), dann bist du da verloren.

Was noch ginge waere zu versuchen den Python-Code zu signieren. Dann kannst nur *du* den erstellen/testen, aber keiner sonst.

@LuckyLuke79: Es ist in .NET selbst nicht möglich, den Zugriff auf einzelne Eigenschaften für bestimmte Objekte zu verhindern. Mag sein, dass IronPython das unterstützt, das müsstest selbst in dessen Dokumentation nachschlagen, ich kenne IronPython nicht.

Falls nicht, kannst Du die Skripte in eine eigene Anwendungsdomäne (siehe "System.AppDomain") laden. Anwendungsdomänen sind so etwas wie unabhängige Programmteile, und die Laufzeitumgebung verhindert den Zugriff auf Objekte einer anderen Anwendungsdomäne. Damit Deine Skripte trotzdem auf Objekte des Programms zugreifen können, musst Du für jedes Objekt, dass einem Skript zur Verfügung gestellt werden soll, eine Wrapper-Klasse implementieren, die von "MarshalByRefObject" ableitet. Der Rückgabewerte jeder Methode und jeder Eigenschaft, die ein solches Objekt exportiert, muss ebenfalls von "MarshalByRefObject" ableiten.

Je nachdem, wie viele Klassen Dein Programm hat, wird das sehr aufwendig. Zudem sind manche Dinge dann effektiv unmöglich, da Skripte niemals auf ursprünglichen Objekte zugreifen können, und auch keine Objekte direkt aus ihrer Domäne in das Programm injizieren können. Mithin ist die Vererbungshierarchie über die Grenze der Anwendungsdomäne hin anders, und Skripte können beispielsweise keine Knöpfe in der GUI anzeigen, eben da sie kein "Button"-Objekt in das Programm injizieren können.

Ich sehe die Sache allerdings ebenso wie deets: Ein lokal installiertes GUI-Programm unterliegt ohnehin keiner Kontrolle, und kann so ziemlich alles veranstalten, selbst wenn Du den Zugriff auf einige Eigenschaften einschränken könntest. Der Praktikant könnte mit einem Skript beispielsweise auch einfach das Benutzerverzeichnis der „Dame“ löschen, oder nur die Desktop-Verknüpfung Deines Programms durch eine auf Solitär ersetzen, usw. Das ließe sich zwar mit den Mittel des .NET Frameworks ebenfalls verhindern, doch das ist dann sehr aufwendig, weil Du eine Whitelist mit erlaubten Operationen definieren musst.

Mehr noch, wenn Du Deinem Praktikanten derartige Scherze zutraust, dann hast Du schon den ersten Fehler begangen, wenn Du ihn überhaupt an die Computer zugreifen lässt. Denn für die obig beschrieben Scherze braucht man nicht mal ein Skript, das geht auch direkt im Windows Explorer

deets hat geschrieben:Was noch ginge waere zu versuchen den Python-Code zu signieren. Dann kannst nur *du* den erstellen/testen, aber keiner sonst.

DAS ist jetzt wirklich eine Idee, auf die ich noch gar nicht gekommen bin.
Herzlichen Dank! Das hilft mir weiter.

@lunar
Danke für deine Antwort.
Ja, daran hab ich auch schon gedacht. War mir dann aber wirklich zu aufwändig und ist schwieriger zu warten, weshalb ich erstmal weiter gegoogelt und hier im Forum gefragt hab.
Nur signierte Skripte zuzulassen ist da tatsächlich viel einfacher und schneller umgesetzt und genügt der Sicherheit vollkommen.

Gruß
Lucky