スタック検査の制限


8

これは、スタック検査仕組みのフォローアップです。概念をより詳細に探索します

スタック検査は、外部からダウンロードされた信頼レベルの異なるコードモジュールが一緒に実行されている可能性がある場合に、JVMおよびCLR仮想マシンのコンテキストでセキュリティを確保するためのメカニズムです。そのシステムライブラリには、信頼されていないコードからの呼び出しと、信頼されたアプリケーション自体からの呼び出しを区別する方法が必要です。これは、その起源に対応するプリンシパルをコードに関連付けることによって行われます。次に、アクセス許可がスタックに記録され、機密のシステムメソッドへの呼び出しが行われるたびに、スタックがトラバースされ、呼び出しを行うプリンシパルに適切なアクセス許可がスタックに存在するかどうかが確認されます。

スタック検査の制限は何ですか?それを置き換えるためにどのようなメカニズムが提案されていますか?90年代後半に導入されてから、モデルに大きな変更が加えられましたか?


スタック検査の仕組みを完全に理解するのに苦労しています。良い説明へのリンクを添えていただけませんか?
ラファエル

@ラファエル:いい質問だ。:私はそれを疑問作ったcs.stackexchange.com/questions/796/...
デイブ・クラーク

1
スタック検査モデルのいくつかの制限がのJVMとMicrosoft CLR(しかし、私は今それを発見し、私は唯一の結論を読んで)で使用されるこの論文問題:research.microsoft.com/en-us/um/people/adg/Publications/...
2012年

回答:


6

JVMおよびCLR上のプログラムは危険な操作にデフォルトでアクセスできるため、スタック検査が必要です。したがって、災害を防ぐために何かを行う必要があります。たとえば、信頼できないプログラムはI / Oライブラリを参照して呼び出すことができます。

using IO;
...
IO.DeleteFile("/home/foo/bla");

したがって、危険な操作が行われるたびに、それが許可されているかどうかを確認する必要があります。スタック検査では、誰が何にアクセスできるかを理解することは一般に複雑です。また、インライン化や末尾呼び出しなどの最適化も困難になります。

優れたメカニズムは、そもそも各プログラムに危険な操作への自動アクセスを与えないことです。このモデルでは、IOライブラリをインポートする方法はありません。IOライブラリにアクセスする唯一の方法は、他の誰かがあなたにそれを与えた場合です。これは機能セキュリティと呼ばれます。概要はここにあります

代わりに、前のプログラムを次のように記述します。

Main(IOLibrary IO){
  IO.DeleteFile("/home/foo/bla");
}

IOライブラリはプログラムのエントリポイントへのパラメータであり、これは機能と呼ばれます(この場合、IOを実行するために何らかの機能を使用するため)。このプログラムを実行できるようにするには、自分でIO機能にアクセスし、を呼び出してプログラムを実行する必要がありますMain(ourIOlibrary)。信頼されていないプログラムを実行している場合は、ファイルを削除するためにそのライブラリを使用する可能性があるため、IOライブラリを渡さないだけです。場合によっては、信頼できないプログラムにファイルシステムへの限定的なアクセスを許可する必要があります。その場合、特定のディレクトリへのアクセスのみを許可する独自のIOライブラリの周りにラッパーを作成し、それを完全なIOライブラリではなく信頼できないプログラムに渡します

したがって、IO機能を必要とするプログラムを呼び出すためにIO機能が必要な場合、それは、プログラムを呼び出すものすべてが、それを提供できるようにIO機能にアクセスする必要があることを意味します。では、IO機能はどこから来たのでしょうか。さて、やがてコンピュータを操作している人間がプログラムを呼び出したところがあります。この人間はすべてのシステム機能にアクセスできるため、IO機能を渡すことができました。この人間が実行しているプログラムを信頼していない場合、IO機能は渡されません。

おそらく他の種類の機能を簡単に想像できます。インターネットアクセス、画面上に描画するものへのアクセスなど。たとえば、セキュリティで保護されたブラウザプラグインシステムは、定義済みの四角形にグラフィックスを描画することのみを許可する信頼できないプラグインにグラフィックス機能を与える場合があります。ページ上。


5

従来実装されていたスタック検査の1つの制限は、適切な末尾呼び出しが中断されることです。特に、一般的な実装では、「スタック」全体を常に維持する必要があります。ClementsとFelleisenは、「継続マーク」と呼ばれる手法を使用して、ESOP 2003のスタック検査のためのテール再帰セマンティクスの論文で、この問題をどのように解決できるかを示しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.