BT

Code Access Securityは、.NET 4 Beta 2では、もう使用されない

| 作者: Abel Avram , 翻訳者 編集部N 投稿日 2010年1月31日. 推定読書時間: 1分未満 |

原文(投稿日:2010/01/26)へのリンク

.NET Framework 1.0から、Microsoftは、 Code Access Security (CAS)を、マネージコードの能力を割り当てたり、コントロールする手段として導入した。Framework 4.0 Beta 2では、CASを非推奨にして、既定ではオフにする、そして Security Transparency Level 2を導入する。

Javaに対して、.NETが優位を得るのに役立つ、すばらしいフィーチャだ、とかつては考えられたが、その複雑さと、もし適切に使われないとセキュリティホールを実際に作ってしまう可能性のために、.NET開発者の間では、CASは、不評だった。更に、ネイティブなアプリケーションすなわち、非マネージコードは、相変わらず、完全信頼 (FullTrust)で動作するので、CASは、それほど役に立たないものである。

.NET Framework 4.0では、CASは、オフなので、Windows Explorerあるいは、コマンドプロンプトから起動されたすべてのアプリケーションは、完全信頼で走る。ホストされた.NETアプリケーションすなわち、Internet Explorer や ASP.NET内で走るアプリケーションは、ホストから与えられた信頼レベル、部分信頼で走る。

この変更のために、現在開発中のコードは、警告や実行時例外を起こすかもしれない:

これらのセキュリティ・ポリシーの変更により、古くなったCASのポリシーのタイプやメンバを明示的にあるいは暗黙的に(他のタイプやメンバを通して)呼ぶと、コンパイラ警告になったり、実行時例外になったりするかもしれない。古くなったタイプやメンバとそれらの代替のリストについては、 Code Access Security Policy Compatibility and Migration(CASポリシーの互換性と移行)を参照。

実行時の設定スキーマにある <NetFx40_LegacySecurityPolicy> 設定要素 を使って、従来のCASポリシーの動きを選んで、警告やエラーを避けることができる。しかし、従来のセキュリティポリシーの使用を選ぶと、.NET Framework 4 Beta 2に移行しない限り、そのバージョン用のカスタムなCASポリシーは、含まないことになる。

.NET 4.0 Beta 2は、.NET 2.0で導入され、Microsoftの内部で使用されている Security Transparency (セキュリティ上の透過性)と呼ばれる以前のフィーチャを拡張している。サンドボックスで走るマネージコードは、透過的であると考えられる、そのホストによって許された操作しか実行できないので、結果的に安全であると考えられるからである。 Security Transparency Level 2 は、新しい要素を導入する:

.NET Framework 4 Beta 2では、透過性は、強制的なメカニズムで、インフラの一部として走るコードからアプリケーションの一部として走るコードを分離する。透過性は、ネイティブコードを呼ぶような特権的なことができるコード(クリティカルなコード)とそういうことができないコード(透過的なコード)の間に境界を設ける。透過的なコードは、動作している許可の範囲内で、コマンドを実行できるが、クリティカルなコードを実行したり、呼んだり、派生したり、あるいは含んだりすることは、できない。

透過性を強制することの第一の目的は、特権に基づいて、違うグループを隔離する簡単で、効果的なメカニズムを提供することである。サンドボックスのモデルでは、これらのグループは、完全信頼(すなわち、制限なし)と部分信頼(すなわち、サンドボックスに与えられた許可に限定)のどちらかだった。

デスクトップアプリケーションは、完全信頼で走る;透過性のモデルによって何も影響されない。

.NET 4.0では、3タイプのコードがある:transparent(透過的な)コード、security-safe-critical(セキュリティ上安全でクリティカルな)コード、そしてsecurity-critical(セキュリティ上クリティカル)なコードである:

  • 完全信頼で走るコードを含んで、transparentなコードは、他のtransparentなコードかsecurity-safe-criticalしか呼べない。ドメインの部分信頼の(もしあれば)パーミッション・セットによって許されていることしかできない。transparentなコードは、次のことは、できない:

    • Assert あるいは、特権の昇格を実行する

    • 安全でないあるいは検証できないコードを含む

    • criticalなコードを直接呼ぶ

    • ネイティブなコードあるいは SuppressUnmanagedCodeSecurityAttribute 属性を持つコードを呼ぶ

    • LinkDemandによって守られたメンバを呼ぶ

    • critical なタイプから継承する

    更に、transparentなメソッドは、criticalな仮想メソッドをオーバーライドしたり、criticalなインターフェースのメソッドを実装したりできない。

  • safe-criticalなコードは、完全信頼であるが、transparentなコードから呼ぶことができる。完全信頼コードの限られた表面をさらす。正しさとセキュリティの検証がsafe-criticalコードで行われる。

  • security-criticalは、どのタイプのコードを呼ぶことができ、完全信頼である。transparentなコードから呼ぶことはできない。

もし以前の.NET Frameworkのバージョンで走るアプリケーションを作るのであれば、なおCASを使うことができるが、4.0 Beta 2とそれ以降で提供される最新のフィーチャを使うことは、できないだろう。その代わりに、 Windows Software Restriction Policies (SRP)を使うことが推奨されている。SRPは、マネージコードそしてネイティブなアプリケーションの両方に適用できる、より単純なセキュリティメカニズムを提供する。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT