2013-06-06 7 views
5

私は現在、サンドボックス内で信頼できないコードを実行する最良の方法を理解するために、Javaのセキュリティメカニズムをたくさん試しています。保護したいものの1つは無限ループなので、信頼できないコードを独自のスレッドで実行するのが理想的です。今、もちろん、悪質なコードは、例えば、ぶら下がっているスレッドの結果として重い処理を行う可能性があります。このスレッドを根本的に排除するには、Javaの廃止予定のThread.stop()メカニズムを使用する方法があります。これが問題となる主な理由は、スレッドによって保持されているすべてのロックが解放され、オブジェクトが破損する可能性があるためです。Java:ロックの取得を監視

問題は、JavaのSecurityManagerとカスタムクラスローダーでは、どのクラスをロードでき、どのシステムリソースにアクセスできるかなどを追跡できます。コードがロックを獲得することを知らせる(そして潜在的に禁止する)方法があります(たとえば、現在のスレッドが同期ブロックに入る前に通知されるコールバックを定義するなど)。

答えて

4

すでにカスタムクラスローダーを使用している場合は、ロードする前に各クラスのバイトコードを検査し、ロック(monitreter)を取得する命令が含まれている場合はそれを検出できます。

stop()でリリースされたロックは、他のコードがロックする可能性のある共有オブジェクトで取得された場合にのみ問題になることも考慮する必要があります。そのようなオブジェクトが「悪」スレッドでアクセス可能にならないようにすることができれば、あなたは安全です。

+0

実際には、ロックを取得する可能性があるため、クラスを破棄したくないのが理想です。私はもちろん、Java *のどのクラスでも動作しないという点を除いて、コールバックのロードと挿入中にバイトコードを変更することができます。 monitorenterは、VMにロックを取得するよう指示する唯一のバイトコード命令ですか? –

+0

しかし、monitorenterは同期ブロックのコンパイル時にのみ生成され、synchronizedメソッドの呼び出し時はロック取得が暗黙的に行われます。したがって、スレッドが同期メソッドで共有オブジェクトへのアクセスを取得しないようにする必要もあります。コードがjava。*にある場合、悪いとは思わないでください:) –

+0

java。*のコードは悪ではありません。ただし、java。*のオブジェクトがjava.concurrentのキューなどで共有されている場合、そのオブジェクトは外部から使用されていてもjava。*内から取得されます。 –