6

私はIronPythonをゲームエンジンに埋め込んでいます。ゲームエンジンでは、スクリプトをオブジェクトにアタッチできます。スクリプトがいつでもCLRにアクセスできるようにしたくありません。そうすれば、スクリプトはほとんど何でもできるからです。

特にインターネットからダウンロードした場合、ランダムなスクリプトを使用したり、インターネット接続を開いたり、ユーザーのHDDにアクセスしたり、ゲーム内の状態を変更したりできることは、非常に悪いことです。

通常、人々は「別のAppDomainを使用する」と提案するだけです。ただし、私がひどく誤解しない限り、クロスAppDomainは低速です。非常に遅い。ゲームエンジンには遅すぎます。だから私は代替案を探しています。

clrまたは任意の名前空間をインポートできないようにするIronPythonのカスタムバージョンをコンパイルして、標準ライブラリに制限することを考えました。

私がむしろ行きたいオプションは、次の行に沿っています：

__builtins__.__import__ = None #Stops imports working
reload = None #Stops reloading working (specifically stops them reloading builtins
          #giving back an unbroken __import___!

私はこれを別のスタックオーバーフローの投稿で読みました。__builtins_を設定する代わりに。_ import__をnoneに設定します。代わりに、標準APIをロードできるカスタム関数に設定します。

問題は、上記の方法を使用して、スクリプトがclrモジュール、.net BCL、または潜在的に悪いことをする可能性のある他の何かにアクセスできるようにする方法はありますか？または、ソースを変更する必要がありますか？3番目のオプション？

4

2 に答える 2

3

それを保証する唯一の方法は、AppDomain を使用することです。パフォーマンス ヒットが何であるかはわかりません。ユースケースに依存するため、実際に遅すぎることを確認するために最初に測定する必要があります。

ベストエフォート システムのみが必要であり、スクリプトが何もインポートする必要がなく、必要なすべてのオブジェクトをホストから提供する場合、スキームは受け入れられるはずです。また、Python 標準ライブラリの配布を避けることもできます。これにより、スペースが節約されます。

外の世界と通信する可能性のあるものがないか、残りのビルトインを確認する必要があります。open、file、input、raw_inputとexecfile思い浮かびますが、他にもあるかもしれません。execも問題になる可能性があり、キーワードであるため、そこに開口部がある場合はオフにするのが難しい場合があります. 断固たるアタッカーの能力を決して過小評価しないでください!

于 2012-05-29T16:10:12.550 に答える
3

以前に Iron Python をアプリに埋め込んだことがあり、同様のセキュリティ上の懸念を共有しました。リスクを軽減するために私が行ったのは、スクリプト ランタイム専用の特別なオブジェクトを作成することでした。これは、本質的に、「安全な」機能のみを公開するコア オブジェクトのラッパーでした。

スクリプト作成専用のオブジェクトを作成することのもう 1 つの利点は、スクリプトをより簡潔で整然としたものにするヘルパー関数を使用して、スクリプト作成用にオブジェクトを最適化できることです。

Appdomain であろうとなかろうと、誰かが外部の .py モジュールをスクリプトにロードするのを止めるものは何もありません....柔軟性のために支払う代償です。

于 2012-11-06T14:31:24.237 に答える